Section 13.6. Adding High-Demand Items

13.6. Adding High-Demand Items

Now we could tackle the high-demand rental items. "We simply need another given column," Don pointed out. So he added the new high demand column, with all rows having a value of 0. He was about to add some more rows for when the high demand value is not zero; we suggested that they go into a second table.

"I'll change the name of the calculated field to exTRa hours()," added Don. "And the test values in the second table should be changed too." This gave us Figures 13.7 and 13.8.

Figure 13.7. High Demand Added

rent.CalculateLateHours
hours late	grace	count grace	high demand	extra hours()
0	1	yes	0	0
0.9	1	no	0	0
1	1	yes	0	1
1	1	no	0	0
9	1	yes	0	9
19	2	no	0	17

Figure 13.8. A Second Table, with High Demand More Than Zero

rent.CalculateLateHours
hours late	grace	count grace	high demand	extra hours()
0	1	yes	10	0
0.9	1	no	10	0
1	1	yes	5	6
1	1	no	12	0
9	1	no	10	18
19	2	no	100	117

Questions & Answers

Q1:	It wasn't easy to follow all the details of this lateness example.
A1:	That's OK; a lot of business-specific detail is involved here, which would take some time to fully understand. The first point of this example is to show the process of several people understanding nontrivial business rules through writing tests. The second point is how to focus on choosing a suitable area for writing the first tests, in order to gain experience.
Q2:	Does it usually take this much back and forth to zoom in on suitable tests?
A2:	Yes, it can; this scenario is not at all unusual. It depends on the experience of the people, on how well they understand the business rules, and on the number of perspectives. People are often surprised at how simple or how difficult it can be to express rules with suitable tests, owing to a fuzziness in thinking about the rules or conflicting values that underlie them. So you can't necessarily tell beforehand how long it will take. Different goals and points of view may need to be resolved in order to make progress.
Q3:	Our business rules are poorly documented or are out of date. Someone proposing to change them doesn't take account of what we've learned in the past. Test tables would help there, even if they weren't automated.
A3:	Yes, you're right; the tests document the interesting cases. However, there is an underrated value in automating the tests: In building the system to satisfy the tests, programmers often find little inconsistencies between the different tests, and these are important to resolve. The system under test tests the tests as much as the tests test the system under test. Together, they ensure that the documentation is kept up to date.
Q4:	How do you handle a bug report once you introduce automated tests?
A4:	Write a Fit test for it and add it to the test suite. The test suite should be run regularly, at least once a day. And then, once it's fixed, the bug can't come back for long without being picked up by the test.

So far, we'd spent less than an hour on the tests, and we'd made good progress. We started to discuss the final stephow the grace period is calculatedbut it was lunchtime. Emily and Don figured that they could do that by themselves after lunch, so we left them to it.