Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
688
Chapter 26 Design-for-Testability Patterns
The well-known intermediary may be called a “Service Locator,” “Object
Factory,” “Component Broker,” or “Component Registry.” While these names
imply different semantics (new versus existing objects), this need not be the case.
For performance reasons, we may choose to return new objects from a “Service
Locator” or “previously enjoyed” objects from an Object Factory. To simplify
this discussion, the term “Component Broker” is used here.
Implementation Notes
A desire to use a Test Double when testing our code implies a need to make DOCs
substitutable. This constraint rules out hard-coding the names of classes on which
we depend into our code because static binding severely limits our options regard-
ing how the software is confi gured as it runs. One way to avoid this issue is to
have the SUT delegate DOC fabrication to another object. Of course, this scheme
implies we need a way to get a reference to that object. We solve this recursive
problem by having a well-known object act as an intermediary between the test
and the DOC. This well-known object is referenced by a hard-coded classname.
To be useful for installing Test Doubles, this well-known object must supply a
mechanism by which the test can specify the object to be returned.
Dependency Lookup has the following characteristics:
• Either a Singleton [GOF], a Registry [PEAA], or some kind of Thread-
Specifi c Storage [POSA2]
• An interface that fully encapsulates which implementation we are using
• A built-in substitution mechanism for replacing the returned object
with a Test Double
• Access via well-known global name
The Dependency Lookup mechanism returns an object that can be used directly
by the client. The nature of the actual object returned determines whether it is
more appropriate to call it a “Service Locator” or an “Object Factory.” Once
the object is retrieved, the SUT uses it directly. During testing, the test arranges
for the Dependency Lookup mechanism to return a test-specifi c object.
Encapsulated Implementation
A major requirement of Dependency Lookup is the existence of a well-known
object to which we can delegate our requests for DOCs. This well-known
Dependency
Lookup
689
object could be a Singleton, a Registry, or some kind of Thread-Specifi c Storage
mechanism.
3
The “Component Broker” should encapsulate its implementation from the
client (our SUT). That is, the interface provided by the “Component Broker”
should not expose whether it is a Singleton or a Registry or whether some type
of Thread-Specifi c Storage mechanism is in use under the covers. In fact, the
test environment may want to provide a different implementation specifi cally to
avoid issues caused by Singletons in tests, such as a Substitutable Singleton (see
Test-Specifi c Subclass on page 579).
Substitution Mechanism
When a test wants to replace the real DOC with a Test Double, it needs a way
to tell the “Component Broker” that a Test Double should be returned instead
of the real component. The “Component Broker” may provide a confi guration
interface to confi gure it with the object to be returned or the test can replace the
component Registry with a suitable Test-Specifi c Subclass. It may also need to
provide a way to restore the original or default confi guration of the broker so
that the confi guration used in one test does not “leak” into another test, effec-
tively changing the “Component Broker” into a Shared Fixture (page 317).
A less desirable confi guration alternative is to have the “Component Broker”
read the classnames to be constructed for each request from a confi guration fi le.
This approach poses several problems, however. First, the test must write the
fi le as part of fi xture setup unless the test offers a way to replace the fi le access
mechanism. This is sure to result in Slow Tests (page 253). Second, this scheme
will not work with Confi gurable Test Doubles (page 558) unless the confi gura-
tion fi le can also provide initialization data for the object. Finally, the need to
write a fi le opens the door to Interacting Tests (see Erratic Test on page 228)
because different tests may need different confi guration information.
If the “Component Broker” must return objects based on confi guration data,
a better solution is to have a separate
Humble Object (page 695) read the fi le
and call a confi guration interface on the “Component Broker.” The test can
then use this same interface to confi gure the broker on a per-test basis.
3
The main difference is that a Singleton has only a single instance, whereas a Registry
makes no such promise. Thread-Specifi c Storage allows objects to access “global” data
via a well-known object, where the data accessed is specifi c to a particular thread; the
same object might retrieve different data depending on which thread is being run.
Dependency Lookup
Dependency
Lookup
690
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 assumes that the current time will
be returned to the SUT by a DOC. The test cannot control which values are
returned by that component (the DefaultTimeProvider), however, so 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 makes this test nondeter-
ministic and pretty much useless. We need to fi nd a way to gain control over
the indirect inputs of the SUT.
Refactoring Notes
The fi rst step to making this behavior testable is to replace the hard-coded
classname with a call to a “Service Locator”:
public String getCurrentTimeAsHtmlFragment() {
Calendar currentTime;
try {
TimeProvider timeProvider =
(TimeProvider) ServiceLocator.getInstance().
findService("Time");
currentTime = timeProvider.getTime();
} catch (Exception e) {
return e.getMessage();
}
// etc.
Dependency
Lookup
691
Although we could have provided a class method to avoid the chained method
calls, that step would just move the getInstance into the class method. The next
refactoring step depends on whether we have a confi guration interface on our
“Service Locator.” If it makes sense to confi gure the production version of the
“Service Locator,” we can introduce the confi guration mechanism directly into
it (as illustrated in the next example). Otherwise, we can simply override what
the Service Locator returns in a Test-Specifi c Subclass (as illustrated in the sec-
ond example).
Example: Confi gurable Registry
This version of the test has been modifi ed to use the confi guration interface on
the “Service Locator” to install a Test Double:
public void testDisplayCurrentTime_AtMidnight_CSL() {
// Fixture setup
// Test Double configuration
MidnightTimeProvider tpStub = new MidnightTimeProvider();
// Instantiate SUT
TimeDisplay sut = new TimeDisplay();
// Test Double installation
ServiceLocator.getInstance().registerServiceForName(tpStub, "Time");
// Exercise SUT
String result = sut.getCurrentTimeAsHtmlFragment();
// Verify outcome
String expectedTimeString =
"<span class=\"tinyBoldText\">Midnight</span>";
assertEquals("Midnight", expectedTimeString, result);
}
The code in the SUT was described previously. The code for the Confi guration
Interface (see Confi gurable Test Double) of the Confi gurable Registry follows:
public class ServiceLocator {
protected ServiceLocator() {};
protected static ServiceLocator soleInstance = null;
public static ServiceLocator getInstance() {
if (soleInstance==null)
soleInstance = new ServiceLocator();
return soleInstance;
}
private HashMap providers = new HashMap();
public ServiceProvider findService(String serviceName) {
return (ServiceProvider) providers.get(serviceName);
Dependency Lookup
Dependency
Lookup
692
Chapter 26 Design-for-Testability Patterns
}
// configuration interface
public void registerServiceForName( ServiceProvider provider,
String serviceName) {
providers.put( serviceName, provider);
}
}
The interesting thing about this example is our use of a Confi guration Interface on
a production class rather than a Test Double. In fact, the Confi gurable Registry
avoids the need to use a Test Double by providing the test with a mechanism to
alter the service component the Confi gurable Registry returns.
Example: Substituted Singleton
This version of the test deals with a nonconfi gurable Dependency Lookup
mechanism by replacing the soleInstance of the “Service Locator” with a Sub-
stituted Singleton (see Test-Specifi c Subclass). To ensure the reusability of the
confi guration interface of the Substituted Singleton, we pass the TimeProvider Test
Stub (page 529) as an argument to overrideSoleInstance.
public void testDisplayCurrentTime_AtMidnight_TSS() {
// Fixture setup
// Test Double configuration
MidnightTimeProvider tpStub = new MidnightTimeProvider();
// Instantiate SUT
TimeDisplay sut = new TimeDisplay();
// Test Double installation
// Replaces the entire Service Locator with one that
// always returns our Test Stub
ServiceLocatorTestSingleton.overrideSoleInstance(tpStub);
// Exercise SUT
String result = sut.getCurrentTimeAsHtmlFragment();
// Verify outcome
String expectedTimeString =
"<span class=\"tinyBoldText\">Midnight</span>";
assertEquals("Midnight", expectedTimeString, result);
}
Note how the test overrides the object normally returned by getInstance with an
instance of a Test-Specifi c Subclass. The code for the Singleton follows:
public class ServiceLocator {
protected ServiceLocator() {};
protected static ServiceLocator soleInstance = null;
Dependency
Lookup
693
public static ServiceLocator getInstance() {
if (soleInstance==null)
soleInstance = new ServiceLocator();
return soleInstance;
}
private HashMap providers = new HashMap();
public ServiceProvider findService(String serviceName) {
return (ServiceProvider) providers.get(serviceName);
}
}
Note that we had to make the constructor and soleInstance protected rather than
private to allow them to be overridden by the subclass. Finally, here is the code
for the Substituted Singleton:
public class ServiceLocatorTestSingleton extends ServiceLocator {
private ServiceProvider tpStub;
private ServiceLocatorTestSingleton(TimeProvider newTpStub) {
this.tpStub = newTpStub;
};
// Installation interface
static ServiceLocatorTestSingleton
overrideSoleInstance(TimeProvider tpStub) {
// We could save the real instance before reassigning
// soleInstance so we could restore it later, but we'll
// forego that complexity for this example
soleInstance = new ServiceLocatorTestSingleton( tpStub);
return (ServiceLocatorTestSingleton) soleInstance;
}
// Overridden superclass method
public ServiceProvider findService(String serviceName) {
return tpStub; // Hard-coded; ignores serviceName
}
}
Because it cannot see the private HashMap of providers, this code simply returns
the contents of the tpStub fi eld that it initialized in the constructor.
About the Name
Choosing a name for this pattern was tough. Service Locator and Component
Broker were already in widespread use. Both are good names for use in their
particular circumstance. Unfortunately, neither name can encompass the other,
so I had to come up with another name that unifi ed the two major variants.
Dependency Lookup
Dependency
Lookup
694
Chapter 26 Design-for-Testability Patterns
The name Dependency Injection was already in widespread use for the alter-
nate pattern; a desire for consistency with that name led to using Dependency
Lookup. See the sidebar “What’s in a (Pattern) Name?” on page 576 for more
on this decision-making process.
Dependency
Lookup
695
Humble Object
How can we make code testable when it is too closely coupled
to its environment?
We extract the logic into a separate, easy-to-test component that is decoupled
from its environment.
We are often faced with trying to test software that is closely coupled to
some kind of framework. Examples include visual components (e.g., widgets,
dialogs) and transactional component plug-ins. Testing these objects is diffi cult
because constructing all the objects with which our SUT needs to interact may
be expensive—or even impossible. In other cases, objects may be hard to test
because they run asynchronously; examples include active objects (e.g., threads,
processes, Web servers) and user interfaces. These objects’ asynchronicity intro-
duces uncertainty, a requirement for interprocess coordination, and the need
for delays into tests. Faced with these thorny issues, developers often just give
up on testing this kind of code. The result: Production Bugs (page 268) caused
by Untested Code and Untested Requirements.
Humble Object is a way to bring the logic of these hard-to-instantiate objects
under test in a cost-effective manner.
Teardown
Setup
Exercise
Verify
Testable
Component
Impossible
Dependency
Fixture
Humble
Object
Teardown
Setup
Exercise
Verify
Testable
Component
Impossible
Dependency
Fixture
Humble
Object
Humble Object
Humble
Object
696
Chapter 26 Design-for-Testability Patterns
How It Works
We extract all the logic from the hard-to-test component into a component that
is testable via synchronous tests. This component implements a service interface
consisting of methods that expose the logic of the untestable component; the
only difference is that these methods are accessible via synchronous method
calls. As a result, the Humble Object component becomes a very thin adapter
layer that contains very little code. Each time the framework calls the Humble
Object, this object delegates its responsibilities to the testable component. If
the testable component needs any information from the context, the Humble
Object is responsible for retrieving it and passing it to the testable component.
The Humble Object code is typically so simple that we often don’t bother writing
tests for it because it can be quite diffi cult to set up the environment needed to run
those tests.
When to Use It
We can and should introduce a Humble Object whenever we have nontrivial
logic in a component that is problematic to instantiate because it depends on a
framework or can be accessed only asynchronously. There are lots of reasons
for objects being hard to test; consequently, there are lots of variations in how
we break the dependencies that are required. The following variations are the
most common examples of Humble Object—but we shouldn’t be surprised if
we sometimes need to invent our own variation.
Variation: Humble Dialog
Graphical user interface (GUI) frameworks require us to provide objects to
represent our pages and controls. These objects provide logic to translate user
actions into the underlying system actions and to translate the system responses
back into user recognizable behavior. This logic may involve invoking the
application behind the user interface and/or modifying the state of this or other
visual objects.
Visual objects are very diffi cult to test effi ciently because they are tightly
coupled to the presentation framework that invokes them. To be effective, a
test would need to simulate that environment to provide the visual object with
all the information and facilities it requires. Further complicating the issue is
the fact that these frameworks often run in their own thread of control, which
means that we must use asynchronous tests. These tests are challenging to write,
and they often result in Slow Tests (page 253) and Nondeterministic Tests (see
Erratic Test on page 228). Under these circumstances, we may benefi t by using
Humble
Object
697
a Humble Object to move all of the controller and view-updating logic out of
the framework-dependent object and into a testable object.
Variation: Humble Executable
Many programs contain active objects. Active objects have their own thread of
execution so they can do things in parallel with other activities of the system.
Examples of active objects include anything that runs in a separate process (e.g.,
Windows applications in .exe fi les) or thread (in Java, any object that imple-
ments Runnable). These objects may be launched directly by the client, or they
may be started automatically, process requests from a queue, and send replies
via a return message. Either way, we must write asynchronous tests (complete
with interprocess coordination and/or explicit delays and Neverfail Tests; see
Production Bugs) to verify their behavior.
The Humble Executable pattern provides a way to bring the logic of the exe-
cutable under test without incurring the delays that might otherwise lead to Slow
Tests and Nondeterministic Tests. We extract all the logic from the executable into
a component that is testable via synchronous tests. This component implements
a service interface consisting of methods that expose all logic of the executable;
the only difference is that these methods are accessible via synchronous method
calls. The testable component may be a Windows DLL, a Java JAR containing a
Service Facade [CJ2EEP] class, or some other language component or class that
exposes the services of the executable in a testable way.
The Humble Executable component itself contains very little code. All it
does in its thread of control is to load the testable component (if a True Hum-
ble Object) and delegate to it. As a result, the Humble Executable requires
only one or two tests to verify that it performs this load/delegate function
correctly. Although these tests still take seconds to execute, they have a much
smaller impact on the overall test suite execution time because so few of them
exist. Given that this code will not change very often, these tests can even
be omitted from the suite of tests that developers execute before check-in to
speed up test suite execution times. Of course, we would still prefer to run the
Humble Executable tests as part of the automated build process.
Variation: Humble Transaction Controller
Many applications use databases to persist their state. Fixture setup with databases
can be slow and complex, and leftover fi xtures can wreak havoc with subsequent
tests and test runs. If we are using a Shared Fixture (page 317), the fi xture’s persis-
tence may lead to Erratic Tests. Humble Transaction Controller facilitates testing of
the logic that runs within the transaction by making it possible for the test to control
Humble Object
Humble
Object