Section 33.5. Transactions

33.5. Transactions

Chapter 15 introduced the notion of business transactions. Emily and Neo reviewed Figure 33.3, a Fit table from Section 15.4 on p. 119 that manages such transactions.

Figure 33.3. Handling Transactions

begin transaction for client	Joanna	staff	Bill
rent	100		cup	for	2	weeks
pay with cash $	210.00
complete transaction

They then looked through the GUI code. "Hmmm," Emily commented, "there's such a lot of business logic in the GUI code. See how the current amount owing is encoded in that event-handling code."

"Yes," replied Neo, "the general handling of the whole transaction is tangled up in there. We'll need to pull that out in some way and put it in the domain layer."

After spending some time looking through the GUI code for transaction-specific business logic, Emily and Neo felt that they understood some of what was going on. Neo suggested, "Let's start refactoring out the business logic into a separate class, which can remain with the GUI until things get clearer."

"OK," replied Emily. "We need to pull out the notion of a transaction starting, the things that happen in the transaction, tracking the amount owing and paid, and the transaction completion. How about calling the new class ClientTransaction?"

In small steps, they extracted the transaction business logic into class ClientTransaction, running the GUI-based tests after each change to ensure that they hadn't broken anything. This was slow work that they had to do very carefully. They needed to understand how both the GUI and the transaction code worked, before pulling it apart. Several times, Neo started making a change that Emily questioned. It worked well having two minds working on this.

It was slow to begin with, but as ClientTransaction evolved, it got easier. They found redundant code in various parts of the GUI, which they eliminated with the new class. They were pleased with their new abstraction and felt that they understood better the notion of transactions. Having clear Fit tests helped considerably, as they could incorporate most of the "language" of the tests into the interface of ClientTransaction.

Their experience is very common; test infecting an application usually adds clarity and removes redundancy. The improved modularity makes it easier to find and fix bugs and to make changes in the future.

Having the fixtures call directly into the API also means that some changes, such as method name changes, will be automatically propagated into the fixture code by refactoring tools. Similarly, many inconsistencies will be picked up by the compiler.

This tighter coupling works well, compared to the loose coupling when tests are run through the GUI. For example, if a GUI component is removed or renamed, we won't discover a problem until the tests are run. This delays feedback.