16.3. Using Durations After looking at the new table briefly, Sarah then added, "It would be better to use durations in a cell, such as '1 day 2 hours,' instead of having separate columns for hours, days, and weeks. We should use such durations everywhere." The CalculateFixture tables[1] shown in Figure 16.8 resulted. [1] See Chapter 10 for an introduction to CalculateFixture tables.
Figure 16.8. Fair Charge Tables Using Durations 
Don added, "That's a good start to early and late returns. We'll need to add a lot more tests later." Questions & Answers | Q1: | Instead of checking the days, weeks, and so on, couldn't the tests in Figure 16.7 check the charge, or cost of the rental? | | A1: | Yes, that would be a reasonable way to do it. It means having to calculate the charge, so it's a little more work. | | Q2: | Why have people traditionally not written tests like this? | | A2: | Because it appears to require access to the internals of the system under test. That's the easiest way to carry out such tests but not the only way. As we'll see in Chapter 35, the fixtures may run the tests by controlling the user interface. | | Q3: | Aren't they really tests that programmers should write, given that they are not end-to-end processing? | | A3: | No, because they are concerns of the business. Although some people have a notion that acceptance testing is explicitly end to end, there doesn't seem to be any call for that to stop us. In the early-return example here, and in many other cases, we find business rules that are at the heart of the process incorporated into software. Because they come from business policy, there needs to be clear communication between the businesspeople and the developers about such rules. As we've seen, it's crucial that the tests be expressed as clearly as possible. To cut to their essence, it's necessary to peel away irrelevant detail. |
|
