15.2 Charging a Deposit
The general business rule here is as follows.
As well as the rental charge, a client pays a deposit before taking the rental items. When the client returns the items, the deposit is refunded if the items are in good condition and don't need replacement, fixing, or cleaning. Otherwise, a partial refund is made, or the client is asked to pay extra for the damage.
The group's first step was to add deposit information in the SetUp to the Hire-Items, as last shown in Figure 14.6 on p. 110. After some debate, Don made the deposit $0.00 for the two dispensers; that meant that the previous tests should still pass. As Don argued, "It would be great if we could add more data to the SetUp without breaking the old tests." The others agreed.
Don added cups as an item with a deposit and included the three rental rates: hourly, daily, and weekly, as shown in Figure 15.1.
Figure 15.1 Extend the SetUp
Sarah wrote the test shown in Figure 15.2. She then questioned whether it made sense to have only a weeks column in those tables: "Will we need hours , days , and weeks ?" "Let's wait until we add date/time processing and see what happens," Emily suggested.
Figure 15.2 Rent with a Deposit
Figure 15.3 Rent with a Deposit with Extra Checking Table
Immediately, Don was unhappy with that: "We need to check only the count." Emily added, "And we'd be better checking just the cups, not the other items. Otherwise, when we change the SetUp again, the last table (in Figure 15.3) will fail." Don changed the table to give Figure 15.4, using a SubsetFixture.  He pointed out, "We'll need to have at least one test that checks that the other rental items are not altered at all."
Figure 15.4 Revised Last Table
"We need to write a test for returning the deposit when the rental items are returned," Emily noted. However, she realized, "We really haven't handled payments yet, let alone refunds. Let's leave that until after we do dates."
Questions & Answers
Do you tend to have lots of SetUps or only one for all the tests?
For RentAPartySoftware, a common SetUp was used for almost all the tests. This avoided the need to make up new data for each test, which gets tedious, and it's difficult to remember the particular data. With common SetUp, we could keep a printed copy on hand.
I suppose the downside is that we may have had a little less variation in our tests than we'd have liked. No, maybe not, when I think about it some more.
In general, it depends on the system under test and how many distinct areas of the application there are. It may be that most tests share some common data, and then categories of tests share still more, so it's convenient to have automated support in gathering up the right SetUp to use for a particular test.