Comments on: It’s not all about the acceptance tests http://www.markhneedham.com/blog/2008/10/03/its-not-all-about-the-acceptance-tests/ Thoughts on Software Development Sat, 11 Feb 2012 23:17:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dan Yankowsky http://www.markhneedham.com/blog/2008/10/03/its-not-all-about-the-acceptance-tests/comment-page-1/#comment-873 Dan Yankowsky Thu, 23 Oct 2008 04:35:55 +0000 http://www.markhneedham.com/blog/?p=423#comment-873 To answer the question that you asked at the end of your post, no, I don't think that acceptance tests must go through the UI. I think that acceptance tests should be as small as possible to reflect the acceptance criteria. That criteria of smallness applies both to the length of the test as well as the conceptual size of the test. A test that includes the whole application stack, from database through UI, is larger than a test of just some middle part. Some acceptance criteria are going to be UI-oriented. The tests for these criteria should likely include the UI. On the other hand, some criteria may not mention anything about a UI. For example, banking software will include a lot of backend computation that, while not directly visible in the UI, is still of great interest to the stakeholders. Why not write acceptance tests of this intermediate code? There doesn't appear (to me) to be a silver bullet to handle all acceptance testing cases. The best we have right now are guiding principles, and I don't think there's much common understanding yet on what those should be. For me, the guiding star is that I should be able to show acceptance tests to the person who wrote the story (or to a QA specialist, or to some other non-developer), and it shouldn't be totally alien to them. Together, we should be able to make sense of the acceptance test, and they should be able to actually see any parts of the test that are wrong. Maybe they can't write the test by themselves, and maybe they can't read it on their own, but if I don't feel like I can work through the acceptance test with the person who will be accepting the story, what's the point of the test? To answer the question that you asked at the end of your post, no, I don’t think that acceptance tests must go through the UI. I think that acceptance tests should be as small as possible to reflect the acceptance criteria. That criteria of smallness applies both to the length of the test as well as the conceptual size of the test. A test that includes the whole application stack, from database through UI, is larger than a test of just some middle part.

Some acceptance criteria are going to be UI-oriented. The tests for these criteria should likely include the UI. On the other hand, some criteria may not mention anything about a UI. For example, banking software will include a lot of backend computation that, while not directly visible in the UI, is still of great interest to the stakeholders. Why not write acceptance tests of this intermediate code?

There doesn’t appear (to me) to be a silver bullet to handle all acceptance testing cases. The best we have right now are guiding principles, and I don’t think there’s much common understanding yet on what those should be. For me, the guiding star is that I should be able to show acceptance tests to the person who wrote the story (or to a QA specialist, or to some other non-developer), and it shouldn’t be totally alien to them. Together, we should be able to make sense of the acceptance test, and they should be able to actually see any parts of the test that are wrong. Maybe they can’t write the test by themselves, and maybe they can’t read it on their own, but if I don’t feel like I can work through the acceptance test with the person who will be accepting the story, what’s the point of the test?

]]>