How CTDD Works
How do we know everything that the customer expects ahead of time? On agile projects, we make this easier by splitting features into small, manageable chunks, known as ‘stories’. Often written on a small index card, stories take a form such as this:
* As a retail website customer, I would like to be able to delete items out of my shopping cart so that I can check out with only the items I want.
For each story, we ask the customer to tell us how she will know when this story is complete, in the form of tests and examples. Just as with TDD, before writing any code, we write tests that, when passing, prove the code meets the minimum requirements. These tests are ideally in a form that can be used with an automated tool, but they may also be higher-level tests, or guidelines for later exploratory testing.
Who are these cooperative customers? They’re the people with the domain expertise, who understand business priorities. They may be in sales or marketing, they may be business managers or analysts, they may be end users, they may even be a development manager or customer support. They will most likely need help in writing effective tests that the programmers can use.
Testers provide this help, combining their understanding of the technical requirements of the system with the big picture of what the business needs. Testers ask questions to help elicit requirements and flush out hidden assumptions. For example, with the story above to delete items out of the shopping cart, testers may ask:
* Should there be a dialog for the user to confirm the delete?
* Is there a need to save the deleted items somewhere for later retrieval?
* Can you draw a picture of how the delete interface should look?
* What should happen if all items in the cart are deleted?
* What if the user has two browser sessions open on the same cart, and deletes an item in one of the sessions?
By writing customer tests ahead of coding the features, we can bring hidden assumptions to the surface. Frequent conversations with our customers, going over examples, enable our product owners to get the best possible results.
Teams doing TDD, especially those trying it for the first time, may tend to do only the more obvious, "happy path" tests. Misunderstood requirements and hard-to-find defects may go undetected. Writing customer tests first provides navigation for our project ‘road trip’. The tests help the team identify milestones and landmarks to know if they’re on track. When the tests all pass, we know we’ve reached our destination.