14.3. Split and Restructure The first step was to separate the setup of these tests; moving to a flow style with DoFixture has an impact on these tables. Figure 14.3 shows the common initial sequence of tables. Figure 14.3. Common SetUp Data for Tests 
The second step was to separate the test in Figure 14.2 into two tests: one to test the rentals and the other to test that the partial returns had the right result. Figure 14.4 shows the first one. (We assume that the SetUp from Figure 14.3 will be included, either when using spreadsheets, as discussed in Section 7.1 or when using FitNesse, as discussed in Section 8.4 on p. 62). Figure 14.4. Test Rental 
Figure 14.5 shows the second test. Note that the extra SetUp table at the beginning is almost the same as the final check table in Figure 14.4. Figure 14.5. Test Partial Return 
Tip It is only after writing several tests that their commonality becomes clear. It's often a mistake to focus on the SetUp too early, because you have to guess. As you develop the concrete examples, you can see what commonality arises naturally.
Questions & Answers | Q1: | Shouldn't the tests be based more on the current implementation? | | A1: | It's usually a mistake to do this too closely, because it tends to incorporate unessential details that are based on how the system happens to work rather than on the important business rules that underlie it. Of course, it's also a mistake to invent a whole new system, so that the tests are useless for the current one. As tests are put in place and are run against the current system, they provide a solid foundation on which to ask what-if questions about the future development. | | Q2: | Doesn't that make it difficult to automate? | | A2: | Not necessarily, as long as the essence of the tests matches the underlying system. The fixture code may need to do lots of work in order to keep the tests simple, but that's a good tradeoff, especially given that tools for managing Fit tests are still in their infancy, compared to programming tools. | | Q3: | What do you mean by "essence"? | | A3: | In our current example, the Client, RentalItem, and so on, are essential to the business rule of renting some party items. How the Client information is presented on the GUI and how a particular client is chosen are not essential to the workflow; those elements could be changed without impacting the business process rule. | | Q4: | It's not easy to make decisions about the structure of tables, is it, given that they're rather "technical"? | | A4: | Quite right; it's designing something, a way of "talking" about a part of the system under test. The skills of several people are likely to be needed to get the tables in the right shape with the right vocabulary. Once that's clearer, and businesspeople know what can be said with them, they can then use those structures to write more tests. |
|
