Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
138
Chapter 11 Using Test Doubles
Mock Object compares actual calls received with the previously defi ned expec-
tations using assertions and fails the test on behalf of the Test Method. As a
consequence, we can reuse the logic employed to verify the indirect outputs of
the SUT across all tests that use the same Mock Object. Mock Objects come in
two basic fl avors:
• A strict Mock Object fails the test if the correct calls are received in a
different order than was specifi ed.
• A lenient
2
Mock Object tolerates out-of-order calls. Some lenient Mock
Objects tolerate or even ignore unexpected calls or missed calls. That
is, the Mock Object may verify only those actual calls that correspond
to expected ones.
The following test confi gures a Mock Object with the arguments of the expected
call to logMessage. When the SUT (the removeFlight method) calls logMessage, the
Mock Object asserts that each of the actual arguments equals the expected argu-
ment. If it discovers that any wrong arguments were passed, the test fails.
public void testRemoveFlight_Mock() throws Exception {
// Fixture setup
FlightDto expectedFlightDto = createAnonRegFlight();
// Mock configuration
ConfigurableMockAuditLog mockLog =
new ConfigurableMockAuditLog();
mockLog.setExpectedLogMessage(
helper.getTodaysDateWithoutTime(),
Helper.TEST_USER_NAME,
Helper.REMOVE_FLIGHT_ACTION_CODE,
expectedFlightDto.getFlightNumber());
mockLog.setExpectedNumberCalls(1);
// Mock installation
FlightManagementFacade facade =
new FlightManagementFacadeImpl();
facade.setAuditLog(mockLog);
// Exercise
facade.removeFlight(expectedFlightDto.getFlightNumber());
// Verify
assertFalse("flight still exists after being removed",
facade.flightExists( expectedFlightDto.
getFlightNumber()));
mockLog.verify();
}
2
Lenient Mock Objects are sometimes called “nice,” but “lenient” is a more precise
adjective.
139
Like Test Stubs, Mock Objects often support confi guration with any indirect inputs
required to allow the SUT to advance to the point where it would generate the
indirect outputs they are verifying.
Fake Objects
A Fake Object is quite different from a Test Stub or a Mock Object in that it is nei-
ther directly controlled nor observed by the test. The Fake Object is used to replace
the functionality of the real DOC in a test for reasons other than verifi cation of indi-
rect inputs and outputs. Typically, a Fake Object implements the same functionality
or a subset of the functionality of the real DOC, albeit in a much simpler way. The
most common reasons for using a Fake Object are that the real DOC has not yet
been built, is too slow, or is not available in the test environment.
The sidebar “Faster Tests without Shared Fixtures” (page 319) describes
how my team encapsulated all database access behind a persistence layer
interface and then replaced the persistence layer component with one that used
in-memory hash tables instead of a real database, thereby making our tests run
50 times faster. To do so, we used a Fake Database (see Fake Object) that was
something like this one:
public class InMemoryDatabase implements FlightDao{
private List airports = new Vector();
public Airport createAirport(String airportCode,
String name, String nearbyCity)
throws DataException, InvalidArgumentException {
assertParamtersAreValid( airportCode, name, nearbyCity);
assertAirportDoesntExist( airportCode);
Airport result = new Airport(getNextAirportId(),
airportCode, name, createCity(nearbyCity));
airports.add(result);
return result;
}
public Airport getAirportByPrimaryKey(BigDecimal airportId)
throws DataException, InvalidArgumentException {
assertAirportNotNull(airportId);
Airport result = null;
Iterator i = airports.iterator();
while (i.hasNext()) {
Airport airport = (Airport) i.next();
if (airport.getId().equals(airportId)) {
return airport;
}
}
throw new DataException("Airport not found:"+airportId);
}
Testing with Doubles
140
Chapter 11 Using Test Doubles
Providing the Test Double
There are two approaches to providing a Test Double: a Hand-Built Test Dou-
ble (see Confi gurable Test Double on page 558), which is coded by the test
automater, or a Dynamically Generated Test Double (see Confi gurable Test
Double), which is generated at runtime using a framework or toolkit provided
by some other developer.
3
All generated Test Doubles must be, by their very
nature, Confi gurable Test Doubles; these components are covered in more
detail in the next section. Hand-Built Test Doubles, by contrast, tend to be
Hard-Coded Test Doubles (page 568) but can also be made confi gurable with
some additional effort. The following code sample illustrates a hand-coded
Inner Test Double (see Hard-Coded Test Double) that uses Java’s anonymous
inner class construct:
public void testDisplayCurrentTime_AtMidnight_PS()
throws Exception {
// Fixture setup
// Define and instantiate Test Stub
TimeProvider testStub = new PseudoTimeProvider()
{ // Anonymous inner stub
public Calendar getTime(String timeZone) {
Calendar myTime = new GregorianCalendar();
myTime.set(Calendar.MINUTE, 0);
myTime.set(Calendar.HOUR_OF_DAY, 0);
return myTime;
}
};
// Instantiate SUT
TimeDisplay sut = new TimeDisplay();
// Inject Test Stub into SUT
sut.setTimeProvider(testStub);
// Exercise SUT
String result = sut.getCurrentTimeAsHtmlFragment();
// Verify direct output
String expectedTimeString =
"<span class=\"tinyBoldText\">Midnight</span>";
assertEquals("Midnight", expectedTimeString, result);
}
We can greatly simplify the development of Hand-Built Test Doubles in
statically typed languages such as Java and C# by providing a set of base classes
called Pseudo-Objects (see Hard-Coded Test Double) from which to create sub-
classes. Pseudo-Objects can reduce the number of methods we need to implement
3
JMock and its ports to other languages are good examples of such toolkits. Other toolkits,
such as EasyMock, implement Statically Generated Test Doubles (see Confi gurable Test
Double) by generating code that is then compiled just like a Hand-Built Test Double.
141
in each Test Stub, Test Spy, or Mock Object to just the ones we expect to be
called. They are especially helpful when we are using Inner Test Doubles or Self
Shunts (see Hard-Coded Test Double). The class defi nition for the Pseudo-Object
used in the previous example looks like this:
/**
* Base class for hand-coded Test Stubs and Mock Objects
*/
public class PseudoTimeProvider implements ComplexTimeProvider {
public Calendar getTime() throws TimeProviderEx {
throw new PseudoClassException();
}
public Calendar getTimeDifference(Calendar baseTime,
Calendar otherTime)
throws TimeProviderEx {
throw new PseudoClassException();
}
public Calendar getTime( String timeZone )
throws TimeProviderEx {
throw new PseudoClassException();
}
}
Confi guring the Test Double
Some Test Doubles (specifi cally, Test Stubs and Mock Objects) need to be told
which values to return and/or which values to expect. A Hard-Coded Test
Double receives these instructions at design time from the test automater;
a Confi gurable Test Double is told this information at runtime by the test
(Figure 11.9). A Test Stub or Test Spy needs to be confi gured only with the
values that will be returned by the methods that the SUT is expected to
invoke. A Mock Object also needs to be confi gured with the names and
arguments of all methods we expect the SUT to invoke on it. In all cases, the
test automater ultimately decides with which values to confi gure the Test
Double. Not surprisingly, the primary considerations when making this deci-
sion are the understandability of the test and the potential reusability of the
Test Double code.
Fake Objects do not need to be “confi gured” at runtime because they are just
used by the SUT; later outputs depend on the earlier calls by the SUT. Similarly,
Dummy Objects do not need to be “confi gured” because they should never be
Testing with Doubles
142
Chapter 11 Using Test Doubles
executed.
4
Procedural Test Stubs are typically built as Hard-Coded Test Doubles.
That is, they are hard-coded to return a particular value when the function is
called—thus they are the simplest form of Test Double.
Figure 11.9 A Test Double being confi gured by the test. We can avoid a
proliferation of Hard-Coded Test Doubles classes by passing return values or
expectation to the Confi gurable Test Double at runtime.
A Confi gurable Test Double can provide either a Confi guration Interface (see
Confi gurable Test Double) or a Confi guration Mode (see Confi gurable Test
Double) that the test can use to confi gure the Test Double with the values to
return or expect. As a consequence, Confi gurable Test Doubles are reusable
across many tests. Use of these Confi gurable Test Doubles also makes tests
more understandable because the values used by the Test Double are visible
within the test, thus avoiding the smell of a Mystery Guest (see Obscure Test
on page 186).
So where should this confi guration take place? The installation of the Test
Double should be treated just like any other part of fi xture setup. Alternatives
such as In-line Setup (page 408), Implicit Setup (page 424), and Delegated
Setup (page 411) are all available.
4
A Dummy Object can be used as an observation point to verify that it was never used by
ensuring that the Dummy Object throws an exception if any of its methods are called.
Fixture
Setup
Exercise
Verify
Teardown
SUT
DOC
Test
Double
Installation
Expectations
Configuration
Expectations,
Return Values
Return
Values
Fixture
Setup
Exercise
Verify
Teardown
SUT
DOC
Test
Double
Installation
Expectations
Configuration
Expectations,
Return Values
Return
Values
143
Installing the Test Double
Before we exercise the SUT, we need to “install” any Test Doubles on which
our test depends. The term “install” here serves as a generic way to describe the
process of telling the SUT to use our Test Double, regardless of the exact details
regarding how we do it. The normal sequence is to instantiate the Test Double,
confi gure it if it is a Confi gurable Test Double, and then tell the SUT to use the
Test Double either before or as we exercise the SUT. There are several distinct
ways to “install” the Test Double, and the choice between them may be as much
a matter of style as of necessity if we are designing the SUT for testability. Our
choices may be much more constrained, however, when we try to retrofi t our
tests to an existing design.
The basic choices boil down to Dependency Injection (page 678), in which the
client software tells the SUT which DOC to use; Dependency Lookup (page 686),
in which the SUT delegates the construction or retrieval of the DOC to another
object; and Test Hook, in which the DOC or the calls to it within the SUT
are modifi ed.
If an inversion of control framework is available in our language, our tests
can substitute dependencies without much additional work on our part. This
removes the need for building in the Dependency Injection or Dependency
Lookup mechanism.
Dependency Injection
Dependency Injection is a class of design decoupling in which the client tells the
SUT which DOC to use at runtime (Figure 11.10). The test-driven development
(TDD) movement has greatly increased its popularity because Dependency Injec-
tion makes for more easily tested designs. This pattern also makes it possible to
reuse the SUT more broadly because it removes knowledge of the dependency
from the SUT; often the SUT will be aware of only a generic interface that the
DOC must implement. Dependency Injection comes in several specifi c fl avors,
with the choice between them being largely a matter of taste:
• Setter Injection (see Dependency Injection): The SUT accesses the
DOC through a public attribute (i.e., a variable or property). The test
explicitly sets the attribute after instantiating the SUT to installing the
Test Double. The SUT may have previously initialized the attribute
with the real DOC in its constructor (in which case the test is replac-
ing it) or the SUT may use Lazy Initialization [SBPP] to initialize the
attribute (in which case the SUT will not bother to install the real
DOC).
Testing with Doubles
144
Chapter 11 Using Test Doubles
Figure 11.10 A Test Double being “injected” into the SUT by a test. Using Test
Doubles requires a means to replace the DOC. Using Dependency Injection involves
having the caller supply the dependency to the SUT before or as it is used.
• Constructor Injection (see Dependency Injection): The SUT accesses
the DOC through a private attribute. The test passes the Test Dou-
ble to the SUT via a constructor that takes the DOC to be used as
an explicit argument and initializes the attribute from it. This may be
the primary constructor used by production code clients or it may be
an alternative constructor. In the latter case, the primary constructor
should call this constructor, passing the default DOC to it as an
argument.
• Parameter Injection (see Dependency Injection): The SUT receives
the DOC as a method parameter. The test passes in a Test Double,
whereas the production code passes in the real object.
5
This approach
works well when the API of the SUT takes as a parameter the object
we need to replace. Although Mock Object afi cionados might argue
that designing APIs in this way improves the design of the SUT, it is
not always possible or practical to pass everything required to each
method.
Dependency Lookup
When software is not designed for testability or when Dependency Injection is
not appropriate, we may fi nd it convenient to use Dependency Lookup. This
pattern also removes the knowledge of exactly which DOC should be used from
5
This approach was advocated in the original paper on Mock Objects [ET]. In this paper,
Mock Objects passed as parameters to methods are called “Smart Handlers.”
DOC
Test
Double
Creation
Creation
SUT
Usage
Client
Exercise
Setup
Exercise
Verify
Teardown
Usage
DOC
Test
Double
Creation
Creation
SUT
Usage
Client
Exercise
Setup
Exercise
Verify
Teardown
Usage
145
the SUT, but it does so by having the SUT ask another piece of software to create
or fi nd the DOC on its behalf (Figure 11.11). This opens the door to changing
the DOC at runtime without modifying the SUT’s code. We do have to modify
the behavior of the intermediary somehow, and this is where the specifi c variants
of Dependency Lookup differ from one another:
Figure 11.11 A Service Locator being “confi gured” by a test to return a Test
Double to the SUT. Using Test Doubles requires a means to replace the DOC.
Using Dependency Lookup involves having the SUT ask a well-known object to
provide a reference to the DOC; the test can provide the Service Locator with a
Test Double to return.
• Object Factory (see Dependency Lookup): The SUT creates the DOC
by calling a Factory Method [GOF] on a well-known object instead of
using an object constructor to create the DOC directly. The test explic-
itly tells the Object Factory to create a Test Double instead of a normal
DOC whenever this method is called .
• Service Locator (see Dependency Lookup): The SUT retrieves a previ-
ously created service object by asking a well-known Registry [PEAA]
object for it. The test confi gures the Service Locator to return the Test
Double when the SUT requests the DOC.
The line between these two patterns can become quite blurry when we use Lazy
Initialization to create the object being returned by a Service Locator. Should it
be called an Object Factory instead? Does it really matter which label we apply?
Probably not—hence the generic name of Dependency Lookup.
DOC
Test
Double
Creation
Creation
SUT
Usage
Client
Setup
Exercise
Verify
Teardown
Usage
Exercise
or
Configuration
with Test Double
Usage
Find or Create
DOC
Test
Double
Creation
Creation
SUT
Usage
Client
Setup
Exercise
Verify
Teardown
Usage
Exercise
or
Configuration
with Test Double
Usage
Find or Create
Testing with Doubles
146
Chapter 11 Using Test Doubles
Retrofi tting Testability Using a Test-Specifi c Subclass
Even when none of these mechanisms is built into the SUT, we may be able to
retrofi t them relatively easily by using a Test-Specifi c Subclass.
The use of Singletons [GOF] specifi cally to act as an Object Factory or Service
Locator is common. If the Singleton has hard-coded behavior, we may have to
turn it into a Substitutable Singleton (see Test-Specifi c Subclass on page 579) to
enable overriding the normally returned DOC with our Test Double. The use of
Singletons can be avoided through the use of an IOC tool or a manually coded
Dependency Injection mechanism. Both of these choices are preferable because
they make the test’s dependency on a Test Double more obvious. Singletons
used for other purposes almost always cause headaches when we are writing
tests and should be avoided if possible.
Our test can instantiate a Test-Specifi c Subclass of the SUT to add a Depen-
dency Injection mechanism or to replace other methods of the SUT with test-spe-
cifi c behavior; see Figure 11.12. We can override any logic used to access a DOC,
thereby making it possible to return a Test Double instead of the normal DOC
without modifying the production code. We can also replace the implementations
of any methods being called from the method we are testing with Test Stub-like
behavior, thereby turning the SUT into its own Subclassed Test Double (see Test-
Specifi c Subclass). This is one way to inject indirect inputs into the SUT.
Figure 11.12 Using a Test-Specifi c Subclass of the SUT. When all else fails, we
can always try subclassing the SUT to change or expose functionality we need
to enable testing
Setup
Exercise
Verify
Teardown
Get State
SUT
Method Under Test
Inter nal Method
Test-
Specific
Subclass
Inter nal Method
Overr idden
Self Call
Set State
Create
Exercise
Setup
Exercise
Verify
Teardown
Get State
SUT
Method Under Test
Inter nal Method
Test-
Specific
Subclass
Inter nal Method
Overr idden
Self Call
Set State
Create
Exercise
147
The main prerequisite of using a Test-Specifi c Subclass of the SUT is that the
SUT must use Self-Calls [WWW] to nonprivate methods that implement any
functionality we need to override from the test. Small, single-purpose methods
rule! The main drawback of this approach is that it is possible to accidentally
override parts of the behavior we are intending to test.
We can also subclass the DOC to insert test-specifi c behavior, effectively
turning it into a Subclassed Test Double (Figure 11.13). This strategy is some-
what safer than subclassing the SUT because it avoids the possibility of acci-
dentally overriding those parts of the SUT that we are testing. The trick,
however, is to get the SUT to use the Test-Specifi c Subclass instead of the DOC.
In practice, this implies that we must use one of the Dependency Injection or
Dependency Lookup techniques, unless the DOC is a Singleton. When the SUT
uses a Singleton by calling a static soleInstance method on a hard-coded class
name, the test can cause the soleInstance method to return an instance of a Test
Double by subclassing the Singleton class and initializing the real Singleton’s
soleInstance class variable to hold an instance of the Test Double. The returned
Test Double may need to be a Subclassed Test Double if the type of the vari-
able used to hold the Singleton’s sole instance is hard-coded as the Singleton’s
class. Although we often use this technique to get a Service Locator to return a
different service, but we can also use a Subclassed Test Double directly with-
out an intermediary Service Locator.
Figure 11.13 Using A Test Double subclassed from the DOC. One way to build
a Test Double is to subclass the real class and override the implementation of any
methods we need to control the indirect inputs or verify indirect outputs.
Fixture
Setup
Exercise
Verify
Teardown
SUT
DOC
Sub-
classed
Test
Double
Fixture
Setup
Exercise
Verify
Teardown
SUT
DOC
Sub-
classed
Test
Double
Testing with Doubles