Today I discovered my current clients (who are using Fit to write acceptance tests) are implementing the Fit test support as the last task before completing the story. This is backwards. There are several good reasons why getting the acceptance test(s) running first is better.
After all the code has been implemented, it can be very hard to add the appropriate hooks to allow the code to be driven by tests. This can necessitate code modifications, which is really the last thing you want when you’re trying to get what you think is finished and working code accepted. Test-driven development can be applied not just at the unit test level but also at the acceptance test level. By writing the tests first you can drive the development of code that is inherently testable rather than having testability tacked on after implementation.
The first task - getting the acceptance tests coded and running - gives you a progress indicator for all remaining tasks in the story. As each task is completed, more of the acceptance test goes green.
By the way, it’s a good idea to structure the tasks and the acceptance tests in a complementary fashion: whenever a task has been completed, the next step in the acceptance test should go green. Sometimes this is not easy to achieve, but often it is with a little thought, and it’s always worthwhile trying.
A common error is to not work from the beginning to the end when working on a story. I’ve written about this before. What happens is a bunch of tasks get implemented in a random order and at the end the story doesn’t actually work because the completed tasks are not integrated with one another.
Driving the development from well-written acceptance tests ensures that a sensible unit of work is undertaken, and that work units are completed properly.
The next task is always the one that will let you get more of the acceptance test passing.
The next task is only done when more of the acceptance test passes.
Starting a task that won’t get more of the acceptance test passing is a waste of time and risks integration failure later on.
Automated tests are always useful for detecting regression (things that used to work breaking). If a regression is detected close to when it’s introduced it’s usually easy to fix because it’s clear what has happened. A completed acceptance test will always give value in detecting regressions in future. What’s less obvious is that the acceptance test, even though it’s not fully passing can have value in detecting regressions while a story is in play. In environments where the team is struggling with accidental regressions (more teams are in this position than know it) this can be a powerful advantage in bringing the situation under control.