We implement tricky domain concepts correctly.
Customers have specialized expertise, or domain knowledge, that programmers don’t have. Some areas of the application—what programmers call domain rules—require this expertise. You need to make sure that the programmers understand the domain rules well enough to code them properly in the application. Customer tests help customers communicate their expertise.
Don’t worry; this isn’t as complicated as it sounds. Customer tests are really just examples. Your programmers turn them into automated tests, which they then use to check that they’ve implemented the domain rules correctly. Once the tests are passing, the programmers will include them in their 10-minute build, which will inform the programmers if they ever do anything to break the tests.
To create customer tests, follow the Describe, Demonstrate, Develop processes outlined in the next section. Use this process during the iteration in which you develop the corresponding stories.
Customer tests are for communication.
At the beginning of the iteration, look at your stories and decide whether there are any aspects that programmers might misunderstand. You don’t need to provide examples for everything. Customer tests are for communication, not for proving that the software works. (See No Bugs” in Chapter 7.)
For example, if one of your stories is “Allow invoice deleting,” you don’t need to explain ...