Acceptance Test Driven Development

Doug and I are currently busy replacing a third party library which we’ve used in our product for quite some time. Thus, the first thing we need to do is create a new component which behaves in exactly the same manner as the original component. Once we have that we can start adjusting the code to add features and work in the way we really want.

To ensure we get an exactly compatible replacement, we started out by creating a suite of automated acceptance tests against the original implementation and they all passed.  Then we removed the third party library and they all failed. From there we could gradually begin building our new component by attempting to make each acceptance test pass – one at a time.

It turns out, this is a very effective way to work. We have high-level acceptance tests which give us our overall direction. We pick one of them that is failing to work on and start trying to narrow down why it’s failing by writing a integration test that gives the same error but is more narrowly focussed.  From there we can write a unit test that fails for a very specific, known reason. Then we fix it and move back up. The whole process winds up being:

1. Pick a failing acceptance test.
2. Identify why it fails more narrowly by writing an integration test.
3. Identify why the integration test fails by writing a unit test.
4. Make the unit test pass.
5. Run the unit tests, if any fail go back to step 4.
6. Run the integration tests, if any fail go back to step 3.
7. Run the acceptance tests, if our acceptance test (or one that previously passed) fails go back to step 2.
8. Pick another acceptance test or if there aren’t any failing tests we’re done.

The biggest advantage to this process is that you can ensure that you’re heading in the right direction. You can always ask yourself – does the unit test I’m writing get me closer to making the integration tests pass and does this integration test get me closer to making the acceptance test pass.

It seems to me that you should ideally always have the acceptance tests written for a user story before you start working on it – even if the first step is to sit down with the customer and write the acceptance tests. How else do you know that you did the right thing for the story?