14.2. Cash Rentals To give us some background, Don took us through a few scenarios, using RentEz: A cash rental occurs when someone comes in to rent some party equipment, such as a coffee dispenser, for some time period. It's called "cash" if the client has not made a booking and will pay immediately rather than on account. A staff member at the rental company serves the client, recording the details, if necessary, as well as what the client wants to rent and for how long. A timed record is kept of what the client rented and when; that way, when the rental goods are returned, a check can be made as to whether the client owes more money or is due a refund of the deposit. "For a start, we've decided to ignore several issues and details," said Don. These included The staff member's interacting with the client and entering details Much of the information kept about clients The clock time at the time of renting and when the rental goods were returned A client changes his or her mind at any stage about the rentals A client unable to pay after all, as his or her credit card limit is exceeded The consideration of only daily rental rates, not hourly and weekly rates The client's deposit on the rented goods, to cover damage and/or late return
Once it was clear that they were tackling a suitably sized problem, we left them to it for an hour or so. We returned to find them in the middle of an animated discussion about managing the tests for running totals for charges and deposit refunds. They had written out several tests on the whiteboard and on three large sheets of paper stuck on the wall. "We've got some questions for you, including the best way of handling the hourly and weekly rental rates for RentalItems." Emily had sketched three of the components of their system, as shown in Figure 14.1. "A Client may have several currently rented items. A Rental is an association between a Client and a RentalItem, with additional information, such as the number of RentalItems rented, the date/time the rental started, the period of the rental, and so on." Figure 14.1. The Three Components 
"We've decided to keep the identification of Clients and RentalItems simple at this stage," said Emily, as shown by one of their tests in Figure 14.2. They had used some initial tables in Figure 14.2 to provide some Client and RentalItem data (see the Tip on p. 107). As Emily explained, the tables are as follows. An ActionFixture table[1] is used to start the system under test (setup). [1] See Chapter 4 for an introduction to ActionFixture tables.
A ColumnFixture table[2] is used to define the items that may be rented (setup). [2] See Chapter 3 for an introduction to ColumnFixture tables.
A ColumnFixture table is used to define the clients that are known (setup). An ActionFixture table is used to rent two sets of rental items (action). A RowFixture table[3] checks that the rental has been recorded (check). [3] See Chapter 5 for an introduction to RowFixture tables.
An ActionFixture table is used to return most of the rental items (action). A RowFixture table checks that the outstanding rental is recorded (check).
Three roles are identified in these tables: setup, action, and check. Tables filling these roles occur in most action-based tests, in that order. The first three setup tables were, more or less, included in all their tests. After discussion about the various tests they'd written, we all decided that several changes would be helpful, as we cover in the following sections. Figure 14.2. Test Partial Returns 
Tip A useful technique is to have a compact way of setting up the initial data to use in a test. If that data had to be entered through tables that drive the usual workflow, several problems would arise. It makes the test much longer, more difficult to read, and less clearly focused. The early setup distracts from the main point of the test. If the workflow used to create Clients and RentalItems changes, all the tests that depend on that workflow must be changed.
Yes, that does lead to a little more work for the programmers in creating extra fixtures that handle the setup. However, there are also benefits to this, as we'll see in Chapter 32.
Change the names of the second and third tables to make their intent clear, and use a SetUpFixture fixture[4] to avoid the add() columns. This was better than adding comments to explain what the tables were for. [4] See Section 10.4 on p. 76 for an introduction to SetUpFixture tables.
Split the test into two, because it is testing two actions: rentals and returns. Use DoFixture tables[5] for the actions. Given all the information needed for the actions, this would make the tests more succinct. [5] See Chapter 10 for an introduction to DoFixture tables.
|
