I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.
Myth: Acceptance Tests ensure the correctness of the system
In XP/TDD Progammer (xUnit style) have always carried the burden of ensuring correctness. This is how it should be.
The point of acceptance tests, at least the FIT style “customer” tests that I’m thinking of, is communicating the behaviour of the system. They are the answer to the criticism that XP is anti-documentation. Done well acceptance tests make a better documentation. Better because by plugging the documentation into the code something magical happens: the document becomes alive. As long as we commit to running and keeping the acceptance tests green, it must always describe the system as it evolves.
The primary purpose being documentation, the focus of the tests should be readability over completeness: a couple of examples illustrate that a field must be a date; in a functioning XP team obvious edge cases such as February 29th can be left to (programmer) unit tests.
Myth: Acceptance Tests should be prepared early in the story life-cycle
Acceptance tests are best defined as late as possible. An acceptance test that is not running green, that is not plugged into functioning code, is dead documentation: it describes something ethereal; something that may never be. In lean terms, it is inventory. It has time to get out of date and become unclear to the writer. The value is only realised when it runs against functioning code, and in XP/Agile/Lean we like to realise value soon after the work is done.
Myth: Acceptance tests should be functional (end to end) tests
Did you hear the one about the gynaecologist who decorated his hallway through the letterbox?
Given sufficient tools, enough effort, and considerable skill it might be possible to paper your hall from outside your front door. It’d be a damn site easier to do it close-up, though.
The purpose of XP Acceptance Tests is to communicate how the system works. Functional tests typically need lots of supporting set-up data and can be easily broken by changes to unrelated parts of the system. Get up close: plug the test into the code that expresses the rule under test. If you can’t find an isolated bit of code that expresses the rule, it may be time to reconsider your design. If your test is covering many different concepts, it may be time to reconsider the clarity of your test.
In his Art of Agile book, Jim Shore underlines this point by calling acceptance-style tests Customer Unit Tests.
Acceptance testing myths
I’ll expand on these over the next few days.
- Acceptance tests should be functional (end to end) tests.
- Acceptance tests should be written from the user point of view.
- Acceptance tests should ensure the correctness of the system.
- Acceptance tests should be written by the customer.
- Acceptance tests should be prepared early in the story life-cycle.
- The story is done when all the acceptance tests pass.
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)
