Re: Digest for continuousdelivery@googlegroups.com - 3 Messages in 1 Topic

[David Farley]

On my current project we always, well nearly always, write the acceptance test first. We have a custom annotation indicating that the test is work--in-progress so that we can track test that are present but not being run.

I prefer it this way around for several reasons:

1) A good acceptance test should form an executable specification of the behaviour of the system. So it represents the most concrete form of a "definition of done" for any given story. You know when you are finished because the tests all pass. If you leave it to the end it is less useful as a guide to the requirements.

2) I becoming increasingly convinced that the only useful way to specify an acceptance test effectively is in the language of the problem domain, and never the solution domain. Writing the test ahead of the implementation applies a nice pressure to keep you honest. It is hard to define a tightly-coupled test that asserts specific implementation details when you haven't implemented the solution yet! On the other hand, it is easy - or should be, to state the aims of the story and the sort of behaviours that you expect to see at it's conclusion.

3) Acceptance tests are good at building a broad team understanding of the problem domain, and a good reference. In my opinion they are a much better reference of intent than uint tests, which tend by their nature to be closer to the solution than the problem. Working on the specification in the form of tests makes you think through the problem, isolated from the solution, and in more detail and so the team gains a better understanding of the problem and so the resulting solution will be better.

Practically we have written our own Domain Specific Language (DSL) for expressing acceptance test cases - there is a simple example that expresses these ideas in the book. Typically our business analysts and/or testers will write the first version of an acceptance test. If this is expressing a new interaction with the system that hasn't been tested before they will invent suitable language to describe the requirements. Developers will implement such missing language features alongside the development of the solution and will implement any relevant application-drivers that sit below the DSL to form a glue layer between app and test-case. Often the acceptance test will evolve as understanding of the problem deepens with new test cases being added during the course of development, but we view it as a process smell if tests are not written first.

On a side note: It is very important, actually crucial (I am not usually that dogmatic), that though anyone can create a test, it is developers, the people who can break tests, that are responsible for fixing them. Without that, your loose a vital feed-back loop that makes the process work.

  Dave Farley

On Tue, Mar 27, 2012 at 5:39 AM, <continuou...@googlegroups.com> wrote:

  Today's Topic Summary

Group: http://groups.google.com/group/continuousdelivery/topics

• When adding a feature, which comes first, the acceptance test or the feature? [3 Updates]

 When adding a feature, which comes first, the acceptance test or the feature?