Section 14.4. Which Client

14.4. Which Client

"It's odd to have to mention the Client in every table," suggested Don. "In RentEz, a particular Client is selected and then any rentals, returns, and so on, are carried out within the context of that Client. This would be fine with one or two tests, but as we add more and more tests, there is much more incentive to be concise."

So Don altered the tests again to make the Client implicit after being selected. He decided to use an action in an extra table to select the current Client. This is shown in the revised SetUp tables in Figure 14.6.

Figure 14.6. Changed SetUp to Select the Client

The other tests were then altered to not mention the current Client, as shown in Figures 14.7 and 14.8. To be clear that only the Rentals shown in the last table of each test are for the specified Client (Joanna), Don changed that table to rentals for client.

Figure 14.7. Changed Rental Test

Figure 14.8. Changed Partial Return Test

He also changed the wording of the rentals and returns in the tables to read more easily; it's fine to have empty keywords. The vocabulary we use often changes like this as part of the ongoing dialogue and invention of a good way of expressing tests.

The group had other work to attend to, so we agreed to continue with these tests the next day.

Questions & Answers

Q1:	Why didn't you simply tell them how to do it from the start?
A1:	It's not necessarily that easy to design the tables for a set of tests in one go, and they knew about the business. Settling on a good vocabulary can take time. It's not until you're written several tests that you start to see the pattern of things that need to be said. We all learned something by tackling these tests in this way. And this gives a realistic example of how your tests will evolve.
Q2:	Does that mean that we may have to revise the vocabulary as the system changes?
A2:	Maybe. It depends on the sort of change. Some business changes will simply require you to extend your vocabulary for new tests for new parts of the system. Changes in the business rules may make different distinctions than before, which may require changes in vocabulary when you talk about those rules and thus changes in the vocabulary used in the tests. The tests lose value if they aren't current, and change is inevitable! On the other hand, we want to avoid having to change our essential vocabulary just because the implementation has changed for nonbusiness reasons, such as in the database schema or the GUI. That's why the vocabulary of the tests needs to be oriented to the business, not the current implementation.

Tip

We're really eager to avoid unnecessary repetition in tests generally, not just in the SetUp. As the number of tests grows, the redundancy makes it

• Tedious to write the same stuff over and over

• Annoying when all the copies have to be changed, especially as it is so easy to miss changing some

• More difficult to read and check the tests