Testing Groovy and Java projects - Making Java Groovy - page 190

Formally, the class being tested is known as the caller , and the classes it depends on are
known as collaborators . The goal is to provide controlled implementations of all the col-
laborators so the caller can be tested by itself.
In this section we'll look at an example similar to the one shown in chapter 7 on Spring.
It's simple enough to follow without being totally artificial. The example is a classic bank
account. There's an Account class, an AccountDAO interface, a File-AccountDAO
implementation, and an AccountService class. The layout is shown in figure 6.3 . The
idea is that the service will have a method called transferFunds that sets transaction
boundaries, the DAO class does persistence for the Account , and the Account itself is
just an entity that will be saved and restored from some persistence structure.
Figure 6.3. A UML diagram of a simple banking system that uses a service, and a DAO implementation based on
flat files. Dashed open arrows represent dependencies, solid open arrows are associations, and the dashed closed
arrow indicates implementation.
In this case I'll use a simple file for persistence. Normally I would use a database, but I
want to illustrate how to do a unit test in Groovy with a stub representing the file. In the
process I'll get to discuss the difference between unit tests and integration tests. So far the
tests in this chapter haven't tried to mock any dependent objects, so they can be considered
integration tests. Now I'll look at doing true unit tests.
In addition to the basic classes, figure 6.3 also shows where the techniques in the following
subsections (coerced closures and expandos) will be used for testing.