Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
678
Chapter 26 Design-for-Testability Patterns
Dependency Injection
How do we design the SUT so that we can replace its
dependencies at runtime?
The client provides the depended-on object to the SUT.
Almost every piece of code depends on some other classes, objects, modules, or
procedures. To unit-test a piece of code properly, we would like to isolate the
code from its dependencies. This isolation is diffi cult to achieve if those depen-
dencies are hard-coded in the form of literal classnames.
Dependency Injection is a way to allow the normal coupling between a SUT
and its dependencies to be broken during automated testing.
How It Works
We avoid hard-coding the names of classes on which we depend into our code by
providing some other means for the client or system confi guration to tell the SUT
which objects to use for each dependency as it is executed. As part of the design
of the SUT, we arrange to pass the dependency in to the SUT through the “front
door.” That is, the means to specify the dependency becomes part of the API of
the SUT. We can include it as an argument with each method call, include it on the
constructor, or make it a settable attribute (property).
When to Use It
We need to provide a means to substitute a depended-on component (DOC)
to make it easy to use a Test Double (page 522) while testing our code. Static
DOC
Test
Double
Creation
Creation
SUT
Usage
Client
Exercise
Setup
Exercise
Verify
Teardown
Usage Usage
DOC
Test
Double
Creation
Creation
SUT
Usage
Client
Exercise
Setup
Exercise
Verify
Teardown
Usage Usage
Dependency
Injection
679
binding—that is, specifying exact types or classes at compile time—severely limits
our options regarding how the software is confi gured as it runs. Dynamic binding
creates much more fl exible software by deferring the decision of exactly which
type or class to use until runtime. Dependency Injection is a good choice for com-
municating which class to use when we are designing the software from scratch. It
offers a natural way to design the code when we are doing test-driven development
(TDD) because many of the tests we write for dependent objects seek to replace a
DOC with a Test Double.
When we don’t have complete control over the code we are testing, such as when
we are retrofi tting tests to existing code,
1
we may need to use some other means
to introduce the Test Doubles. If the SUT uses Dependency Lookup (page 686) to
fi nd the DOC, we can override the lookup mechanism to return the Test Double.
We can also use a Test-Specifi c Subclass (page 579) of the SUT to return a Test
Double as long as access to the DOC remains encapsulated behind a method call.
Implementation Notes
Introducing Dependency Injection requires solving two problems. First, we must
be able to use a Test Double wherever the real DOC is used. This constraint is
primarily an issue in statically typed languages because we must convince the
compiler to allow us to pass off a Test Double as the real thing. Second, we must
provide a way to tell the SUT to use the Test Double.
Type Compatibility
Whichever way we choose to install the dependency into the SUT, we must also
ensure that the Test Double we want to replace it with is “type compatible” with
the code that uses the Test Double. This is most easily accomplished if both the
real component and the Test Double implement the same interface (in statically
typed languages) or have the same signature (in dynamically typed languages).
A quick way to introduce a Test Double into existing code is to do an Extract
Interface [Fowler] refactoring on the real DOC and then have the Test Double
implement the new interface.
Installing the Test Double
There are a number of different ways to tell the SUT to use the Test Double, but they
all involve replacing a hard-coded name with a mechanism that determines the type
of object to use at execution time. The three basic options are as follows:
1
“If it ain’t broke, don’t change it (even to improve the testability)” is a common, albeit
somewhat misguided, constraint in these circumstances.
Dependency
Injection
Dependency Injection
680
Chapter 26 Design-for-Testability Patterns
• Parameter Injection: We pass the dependency directly to the SUT as we
invoke it.
• Constructor Injection: We tell the SUT which DOC to use when we
construct it.
• Setter Injection: We tell the SUT about the DOC sometime between
when we construct it and when we exercise it.
Each of these three variations of Dependency Injection can be hand-coded. Another
option is to use an “Inversion of Control” (IoC) framework to link the various
components together at runtime. This scheme avoids superfl uous diversity in how
Dependency Injection is implemented across the application and can simplify the
process of reconfi guring the application for different deployment models.
Variation: Parameter Injection
Parameter Injection is a form of Dependency Injection in which the SUT does not
keep or initialize a reference to the DOC; instead, it is passed in as an argument of
the method being called on the SUT. All clients of the SUT—whether they are tests
or production code—supply the DOC. As a consequence, the SUT is more indepen-
dent of the context because it makes no assumptions about the dependency other
than its usage interface. The main drawback is that Parameter Injection forces the
client to know about the dependency, which is more appropriate in some circum-
stances than in others. Most of the other variants of Dependency Injection move
this knowledge somewhere other than the client or at least make it optional.
Parameter Injection is advocated by the original paper on Mock Objects (page 544)
[ET]. It is especially effective when we are doing true TDD because that’s when we
have the greatest control over the design. It is possible to introduce Parameter In-
jection in an optional fashion by providing an alternative signature for the method
in question with the extra parameter; we can then have the more traditional style
method create the instance of the dependency and call the method that takes the de-
pendency as a parameter.
Variation: Constructor Injection
Both Constructor Injection and Setter Injection involve storing a reference to the
DOC as an attribute (fi eld or instance variable) of the SUT. With Dependency
Injection, the fi eld is initialized from a constructor argument. The SUT may
optionally provide a simpler constructor that calls this constructor with the
value normally used in production. When a test wants to replace the real DOC
with a Test Double, it passes in the Test Double to the constructor when it
builds the SUT.
Dependency
Injection
681
This approach to introducing Dependency Injection works well when the
code includes only one or two constructors and they have small argument
lists. Constructor Injection is the only approach that works if the DOC is an
active object that creates its own thread of execution during construction;
such behavior would make for Hard-to-Test Code (page 209), and we should
probably consider turning it into a Humble Executable (see Humble Object
on page 695). If we have a large number of dependencies as constructor argu-
ments, we probably need to refactor the code to remove this code smell.
Variation: Setter Injection
As with Constructor Injection, the SUT holds a reference to the DOC as an attri-
bute (fi eld) that is initialized in the constructor. Where it differs is that the attribute
is exposed to the client either as a public attribute or via a “setter” method. When
a test wants to replace the real DOC with a Test Double, it assigns to the exposed
attribute (or calls the setter with) an instance of the Test Double. This approach
works well when constructing the real DOC has no unpleasant side effects and
assuming that nothing can happen automatically between the constructor call and
the point at which the test calls the setter for the property. Setter Injection cannot
be used if the SUT performs any signifi cant processing in the constructor that relies
on the dependency. In that case, we must use Constructor Injection. If constructing
the real DOC has deleterious side effects, we can avoid creating it via the construc-
tor by modifying the SUT to use Lazy Initialization [SBPP] to instantiate the DOC
the fi rst time the SUT needs to use it.
Retrofi tting Dependency Injection
When the SUT does not support any of these options “out of the box,” we may
be able to retrofi t this capability via a Test-Specifi c Subclass. If the actual class
to be used is normally retrieved from confi guration data, this retrieval should be
done by some component other than the SUT and the class then passed to the
SUT using Dependency Injection. Such a use of the Humble Object pattern for
the client or confi guration decouples the SUT from the environment and ensures
that tests do not need to set up some external dependency (the confi guration fi le)
to introduce the Test Double.
Another possibility is to use aspect-oriented programming (AOP) to insert
the Dependency Injection mechanism into the development environment. For
example, we might inject the decision to use the Test Double or inject the test-
specifi c logic—the Test Double—directly into the SUT. I don’t think we have
enough experience with using AOP to call this a pattern just yet.
Dependency
Injection
Dependency Injection
682
Chapter 26 Design-for-Testability Patterns
Motivating Example
The following test cannot be made to pass “as is”:
public void testDisplayCurrentTime_AtMidnight() {
// fixture setup
TimeDisplay sut = new TimeDisplay();
// exercise SUT
String result = sut.getCurrentTimeAsHtmlFragment();
// verify direct output
String expectedTimeString =
"<span class=\"tinyBoldText\">Midnight</span>";
assertEquals( expectedTimeString, result);
}
This test almost always fails because it depends on the current time being returned
to the SUT by a DOC. The test cannot control the values being returned by that
component, the DefaultTimeProvider. Therefore, this test will pass only when the
system time is exactly midnight.
public String getCurrentTimeAsHtmlFragment() {
Calendar currentTime;
try {
currentTime = new DefaultTimeProvider().getTime();
} catch (Exception e) {
return e.getMessage();
}
// etc.
}
Because the SUT is hard-coded to use a particular class to retrieve the time, we
cannot replace the DOC with a Test Double. That constraint makes this test
nondeterministic and pretty much useless. We need to fi nd a way to gain control
over the indirect inputs of the SUT.
Refactoring Notes
We can use a Replace Dependency with Test Double (page 522) refactoring to
gain control over the time. Setter Injection can be introduced into existing code if
we have control over the code and the method in question is not widely used or if
we have refactoring tools that support the Introduce Parameter [JBrains] refactor-
ing. Failing that, we can use an Extract Method [Fowler] refactoring to create the
new method signature that takes the Dependency Injection as an argument and
leave the old method as an Adapter [GOF] that calls the new method.
Dependency
Injection
683
Example: Parameter Injection
Here’s the test rewritten to use Parameter Injection:
public void testDisplayCurrentTime_AtMidnight_PI() {
// Fixture setup
// Test Double instantiation
TimeProvider tpStub = new MidnightTimeProvider();
// Instantiate SUT
TimeDisplay sut = new TimeDisplay();
// Exercise SUT using Test Double
String result = sut.getCurrentTimeAsHtmlFragment(tpStub);
// Verify outcome
String expectedTimeString =
"<span class=\"tinyBoldText\">Midnight</span>";
assertEquals("Midnight", expectedTimeString, result);
}
In this case, only the test will use the new signature. The existing code can use
the old signature and the method adapter instantiates the real dependency object
before passing it in.
public String getCurrentTimeAsHtmlFragment(
TimeProvider timeProviderArg) {
Calendar currentTime;
try {
currentTime = timeProviderArg.getTime();
} catch (Exception e) {
return e.getMessage();
}
// etc.
}
Example: Constructor Injection
Here’s the same test rewritten to use Constructor Injection:
public void testDisplayCurrentTime_AtMidnight_CI()
throws Exception {
// Fixture setup
// Test Double instantiation
TimeProvider tpStub = new MidnightTimeProvider();
// Instantiate SUT injecting Test Double
TimeDisplay sut = new TimeDisplay(tpStub);
// Exercise SUT
String expectedTimeString =
"<span class=\"tinyBoldText\">12:01 AM</span>";
// Verify outcome
Dependency Injection
Dependency
Injection
684
Chapter 26 Design-for-Testability Patterns
assertEquals("12:01 AM",
expectedTimeString,
sut.getCurrentTimeAsHtmlFragment());
}
To convert the SUT to use Constructor Injection, we can do an Introduce Field
[JetBrains] refactoring to hold the DOC in a fi eld that is initialized in the existing
constructor. We can then do an Introduce Parameter refactoring to modify all
callers of the existing constructor so that they pass the real DOC as a parameter
of the constructor. If we cannot or do not want to modify all existing callers of the
constructor, we can defi ne a new constructor that takes the DOC as a parameter
and modify the existing constructor to instantiate the real DOC and pass it in to
our new constructor.
public class TimeDisplay {
private TimeProvider timeProvider;
public TimeDisplay() { // backwards compatible constructor
timeProvider = new DefaultTimeProvider();
}
public TimeDisplay(TimeProvider timeProvider) { // new constructor
this.timeProvider = timeProvider;
}
Another approach is to do an Extract Method refactoring on the call to the con-
structor and then use Move Method [Fowler] refactoring to move it to an Object
Factory (see Dependency Lookup). That would result in Dependency Lookup.
Example: Setter Injection
Here is the same test refactored to use Setter Injection:
public void testDisplayCurrentTime_AtMidnight_SI()
throws Exception {
// Fixture setup
// Test Double instantiation
TimeProvider tpStub = new MidnightTimeProvider();
// Instantiate SUT
TimeDisplay sut = new TimeDisplay();
// Test Double installation
sut.setTimeProvider(tpStub);
// Exercise SUT
String result = sut.getCurrentTimeAsHtmlFragment();
// Verify outcome
String expectedTimeString =
"<span class=\"tinyBoldText\">Midnight</span>";
assertEquals("Midnight", expectedTimeString, result);
}
Dependency
Injection
685
Note the call to setTimeProvider to install the Hard-Coded Test Double (page 568).
If we had used a Confi gurable Test Double (page 558), its confi guration would
occur immediately before the call to setTimeProvider.
To refactor the SUT to support Setter Injection, we can do an Introduce
Field refactoring to hold the DOC in a variable that is initialized in the exist-
ing constructor and call the DOC via this fi eld. We can then expose the fi eld
either directly or via a setter so that the test can override its value. Here is the
refactored version of the SUT:
public class TimeDisplay {
private TimeProvider timeProvider;
public TimeDisplay() {
timeProvider = new DefaultTimeProvider();
}
public void setTimeProvider(TimeProvider provider) {
this.timeProvider = provider;
}
public String getCurrentTimeAsHtmlFragment()
throws TimeProviderEx {
Calendar currentTime;
try {
currentTime = getTimeProvider().getTime();
} catch (Exception e) {
return e.getMessage();
}
// etc.
Here we chose to use a getter to retrieve the DOC. We could just as easily have
used the timeProvider fi eld directly.
Dependency Injection
Dependency
Injection
686
Chapter 26 Design-for-Testability Patterns
Dependency Lookup
How do we design the SUT so that we can replace its
dependencies at runtime?
The SUT asks another object to return the depended-on object
before it uses it.
Almost every piece of code depends on some other classes, objects, modules, or
procedures. To unit-test a piece of code properly, we would like to isolate it from
its dependencies. Such isolation is diffi cult to achieve, however, if those depen-
dencies are hard-coded within the code in the form of literal classnames.
Dependency Lookup is a way to allow the normal coupling between a SUT
and its dependencies to be broken during automated testing.
How It Works
We avoid hard-coding the names of classes on which the SUT depends into
our code because static binding severely limits our options regarding how the
software is confi gured as it runs. Instead, we hard-code that name of a “compo-
nent broker” that returns a ready-to-use object. The component broker provides
some means for the client software or perhaps a system confi guration manager
to tell the SUT in question which objects to use for each component request.
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
Dependency
Lookup
Also known as:
Service Locator,
Object Factory,
Component
Broker,
Component
Registry
687
When to Use It
Dependency Lookup is most appropriate when we need to retrieve DOCs
from deep inside the system and it would be too messy to pass the Test Double
(page 522) in from the client. A good example of such a situation is when we
want to replace the data access layer of the system with a Fake Database (see
Fake Object on page 551) or In-Memory Database (see Fake Object) to speed
up execution of the automated customer tests. It would be too complex for each
Subcutaneous Test (see Layer Test on page 337) to pass the Fake Database in
through the Service Facade [CJ2EEP] and all the way down to the data access layer.
Using Dependency Lookup allows the test or even a Setup Decorator (page 447)
to use a “confi guration facade” to install the Fake Database, which the SUT can
magically use without any further ado. Jeremy Miller writes:
You cannot understate the value of using a Service Locator for automated
testing. We routinely use alternative dependencies in testing, both to deal
with diffi cult dependencies and for test performance. For example, in a
functional test we’ll collapse a Web site and a backing application server
into a single process for better performance.
Dependency Lookup tends to be a lot simpler to retrofi t onto existing legacy
software because it affects only those places where object construction actually
occurs; we do not need to modify every intermediate object or method, as we
might have to do with Dependency Injection (page 678). It is also much simpler
to retrofi t existing round-trip tests so that they use a Fake Object to speed them
up by wrapping them in a Setup Decorator. With this scheme, we do not have
to change each test; instead, we can create new instances of the SUT in each
test and still have the test use the same Fake Object because the Service Locator
remembers it across tests.
2
The main alternative to Dependency Lookup is to provide a substitution
mechanism within the SUT using Dependency Injection. This approach is gen-
erally preferable for unit tests because it makes the replacement of the DOC
more obvious and directly connected to exercising the SUT. Another option is
to use AOP to install test-specifi c logic using the development tools rather than
modifying the design of the software. The least preferred solution is to use a
Test Hook (page 709) within the SUT to avoid calling the DOC or within the
DOC so that it behaves in a test-specifi c way.
2
We call these tests “bimodal” or “multimodal” because they can be run with both real
and fake DOCs.
Dependency Lookup
Dependency
Lookup