33.6. Transaction Fixture "Now we need a fixture that connects to the ClientTransaction in RentEz and carries out actions on it," Emily suggested.[1] [1] See Section 28.5 on p. 234 for an introduction to this approach.
"Yes," replied Neo, "we can pass the ClientTransaction object to it when we create the DoFixture." Emily added support for transactions through a separate DoFixture object. The method beginTransactionForClientStaff() in class StartApplication, as shown in Listing 33.4, corresponds to the first action in the Fit table in Figure 33.3. Listing 33.4. StartApplication.java (part 3) public class StartApplication extends DoFixture { private RentEz rentEz; public Fixture beginTransactionForClientStaff(String clientName, String staffMemberName) throws MissingException { ClientTransaction transaction = rentEz.beginClientTransaction( clientName,staffMemberName); return new TransActionFixture(rentEz,transaction); } }
This method returns a new transActionFixture, which defines methods corresponding to the actions used in a transaction table. For example, four of the methods of class transActionFixture are shown in Listing 33.5. Figure 33.4 shows the interaction of the tables, fixtures, and application objects for tests involving a business transaction. Note how the TRansActionFixture object acts directly on the ClientTransaction object within the system under test. Figure 33.4. Managing a Business Transaction 
Questions & Answers | Q1: | Is it usual to have fixtures refer to other system under test objects, such as the ClientTransaction? | | A1: | Yes, and it is desirable to do so, as it keeps the fixture simple and minimizes the dependency of the fixture code on other parts of the system. The fixture objects connect to the domain objects in much the same way that GUI objects do. Listing 33.5. TransActionFixture.java public class TransActionFixture extends fit.DoFixture { private ClientTransaction transaction; private RentEz rentEz; public TransActionFixture(RentEz rentEz, ClientTransaction transaction) { this.rentEz = rentEz; this.transaction = transaction; } public Money rentForWeeks(int count, String hireItemName, int weeks) { return transaction.rent(count,getRentalItemType(hireItemName), new Duration(0,0,weeks)); } public boolean payWithCashDollar(Money amount) { return transaction.payCash(amount); } public boolean refundCashDollar(Money cashAmount) { return transaction.refundCash(cashAmount); } public boolean completeTransaction() { return transaction.complete(); } //... }
| | Q2: | With testing being run through the GUI, the setup time could, presumably, be reduced by writing setup data directly to the database. | | A2: | Yes. If the domain and data source layers are still tangled, so that testing involves the database, the initial fixture can set up the data in the database directly. Then the setup fixtures have nothing to do. Or they could check that the setup data is as expected for the start of the test. | | Q3: | Wouldn't using the setup tables for checking mean that the setup tables would need to be changed to distinquish the various sorts of setup? | | A3: | Yes. Instead of having just set up in the first row of each of the setup tables, we'd need something like set up rental items, set up clients, and so on. |
As the separation of the domain objects and the UI is carried out, one roadblock to testing has been removed. The next hurdle is domain objects that have database managementor other forms of persistencetangled within them. |
