Meszaros G. xUnit Test Patterns Refactoring Test Code

Подождите немного. Документ загружается.

128

Chapter 11 Using Test Doubles

How Do We Control Indirect Inputs?

Testing with indirect inputs is a bit simpler than testing with indirect outputs

because the techniques used to test outputs build on those used to test inputs.

Let’s delve into indirect inputs ﬁ rst.

To test the SUT with indirect inputs, we must be able to control th e DOC

well enough to cause it to return every possible kind of return value. That

implies the availability of a suitable control point.

Examples of the kinds of indirect inputs we want to be able to induce via this

control point include

• Return values of methods/functions

• Values of updatable arguments

• Exceptions that could be thrown

Often, the test can interact with the DOC to set up how it will respond to

requests. For example, if a component provides access to data in a database, then

we can use Back Door Setup (see Back Door Manipulation on page 327) to insert

speciﬁ c values into a database that cause the component to respond in the desired

ways (e.g., no items found, one item found, many items found). (See Figure 11.3.)

In this speciﬁ c case, we can use the database itself as a control point.

Figure 11.3 Using Back Door Manipulation to indirectly control and observe

the SUT. When the SUT stores its state in another component, we may be able

to manipulate that state by having the test interact directly with the other com-

ponent via a “back door.”

In most cases, however, this approach is neither practical nor even possible. We

might not be able to use the real component for the following reasons:

Data

Fixture

Setup

Exercise

Verify

Teardown

SUT

Data

Fixture

Setup

Exercise

Verify

Teardown

SUT

Data

Fixture

Setup

Exercise

Verify

Teardown

SUT

Data

Fixture

Setup

Exercise

Verify

Teardown

SUT

129

What Are Indirect Inputs and Outputs?

• The real component cannot be manipulated to produce the desired

indirect input. Only a true software error within the real component

would result in the desired input to the SUT.

• The real component could be manipulated to make the input occur but

doing so would not be cost-effective.

• The real component could be manipulated to make the input occur but

doing so could have unacceptable side effects.

• The real component is not yet available for use.

If we cannot use the real component as a control point, then we have to replace

it with one that we can control. This replacement can be done in a number of

different ways, which are the focus of the section Installing the Test Double

later in this chapter. The most common approach is to conﬁ gure a Test

Stub (page 529) with a set of values to return from its functions and then to

install this Test Stub into the SUT. During execution of the SUT, the Test Stub

receives the calls and returns the previously conﬁ gured responses (Figure 11.4).

It has become our control point.

Figure 11.4 Using a Test Stub as a control point for indirect inputs. One way

to use a control point to inject indirect inputs into the SUT is to install a Test

Stub in place of the DOC. Before exercising the SUT, we tell the Test Stub what

it should return to the SUT when it is called. This strategy allows us to force the

SUT through all its code paths.

Fixture

Setup

Exercise

Verify

Teardown

SUT

DOC

Test

Stub

Return

Values

Indirect

Input

Installation

Creation

Fixture

Setup

Exercise

Verify

Teardown

SUT

DOC

Test

Stub

Return

Values

Indirect

Input

Installation

Creation

130

Chapter 11 Using Test Doubles

How Do We Verify Indirect Outputs?

In normal usage, as the SUT is exercised, it interacts naturally with the component(s)

upon which it depends. To test the indirect outputs, we must be able to observe the

calls that the SUT makes to the API of the DOC (Figure 11.5). Furthermore, if we

need the test to progress beyond that point, we need to be able to control the val-

ues returned (as was discussed in the discussion of indirect inputs).

Figure 11.5 Using Behavior Veriﬁ cation to verify the indirect outputs of the SUT.

When we care about exactly what calls our SUT makes to other components, we

may have to do Behavior Veriﬁ cation rather than simply verifying the post-test state

of the SUT.

In many cases, the test can use the DOC as an observation point to ﬁ nd out how

it has been used. For example:

• We can ask the ﬁ le system for the contents of a ﬁ le that the SUT has writ-

ten to verify that it exists and was written with the expected contents.

• We can ask the database for the contents of a table or speciﬁ c record to

verify that the SUT wrote the expected records to the database.

• We can interact directly with the e-mail sending component to ask

whether the SUT had asked it to send a particular e-mail.

These are all examples of Back Door Veriﬁ cation (see Back Door Manipulation

on page 327). Some DOCs allow us to conﬁ gure their behavior in such a way

that we can use them to keep the test informed of how they are being used:

Fixture

DOC

Exercise

Setup

Exercise

Verify

Teardown

SUT

Behavior

(Indirect

Outputs)

Verify

Fixture

DOC

Exercise

Setup

Exercise

Verify

Teardown

SUT

Behavior

(Indirect

Outputs)

Verify

131

• We can ask the ﬁ le system to notify the test whenever a ﬁ le is created or

modiﬁ ed so we can verify its contents.

• We can use a database trigger to notify the test when a record is written

or deleted.

• We can conﬁ gure the e-mail sending component to deliver all outgoing

e-mail to the test.

Sometimes, as we have seen with indirect inputs, it is not practical to use the

real component as an observation point. When all else fails, we may need to

replace the real component with a test-speciﬁ c alternative. For example, we

might need to do this for the following reasons:

• The calls to (or the internal state of) the DOC cannot be queried.

• The real component can be queried but doing so is cost-prohibitive.

• The real component can be queried but doing so has unacceptable side

effects.

• The real component is not yet available for use.

The replacement of the real component can be done in a number of different

ways, as will be discussed in Installing the Test Double.

Two basic styles of indirect output veriﬁ cation are available. Procedural Behav-

ior Veriﬁ cation (see Behavior Veriﬁ cation) captures the calls to a DOC (or their re-

sults) during SUT execution and then compares them with the expected calls after

the SUT has ﬁ nished executing. This veriﬁ cation involves replacing a substitutable

dependency with a Test Spy (page 538). During execution of the SUT, the Test Spy

receives the calls and records them. After the Test Method (page 348) has ﬁ nished

exercising the SUT, it retrieves the actual calls from the Test Spy and uses Assertion

Methods (page 362) to compare them with the expected calls (Figure 11.6).

Expected Behavior (see Behavior Veriﬁ cation) involves building a “behavior

speciﬁ cation” during the ﬁ xture setup phase of the test and then comparing the

actual behavior with this Expected Behavior. It is typically done by loading a

Mock Object (page 544) with a set of expected procedure call descriptions and

installing this object into the SUT (Figure 11.7). During execution of the SUT,

the Mock Object receives the calls and compares them to the previously deﬁ ned

expected calls (the “behavior speciﬁ cation”). As the test proceeds, if the Mock

Object receives an unexpected call, it fails the test immediately. The test failure

traceback will show the exact location in the SUT where the problem occurred

because the Assertion Methods are called from the Mock Object, which is in

turn called by the SUT. We can also see exactly where in the Test Method the

SUT was being exercised.

What Are Indirect Inputs and Outputs?

132

Chapter 11 Using Test Doubles

Figure 11.6 Using a Test Spy as an observation point for indirect outputs of

the SUT. One way to implement Behavior Veriﬁ cation is to install a Test Spy in

place of the target of the indirect outputs. After exercising the SUT, the test asks

the Test Spy for information about how it was used and compares that

information to the expected behavior using assertions.

Figure 11.7 Using a Mock Object as an observation point for indirect outputs

of the SUT. Another way to implement Behavior Veriﬁ cation is to install a Mock

Object in place of the target of the indirect outputs. As the SUT makes calls

to the DOC, the Mock Object uses assertions to compare the actual calls and

arguments with the expected calls and arguments.

Fixture

Setup

Exercise

Verify

Teardown

SUT

Exercise

Test Spy

Installation

Creation

Indirect

Outputs

Indirect

Output

DOC

Fixture

Setup

Exercise

Verify

Teardown

SUT

Exercise

Test Spy

Installation

Creation

Indirect

Outputs

Indirect

Output

DOC

Fixture

DOC

SUT

Mock

Object

Final Verification

Exercise

Creation

Setup

Exercise

Verify

Teardown

Expectations

Installation

Indirect

Output

Verify

Fixture

DOC

SUT

Mock

Object

Final Verification

Exercise

Creation

Setup

Exercise

Verify

Teardown

Expectations

Installation

Indirect

Output

Verify

133

When we use a Test Spy or a Mock Object, we may also have to employ it as a

control point for any indirect inputs on which the SUT depends after the Test

Spy or Mock Object has been called to allow test execution to continue.

Testing with Doubles

By now you are probably wondering about how to replace those inﬂ exible and

uncooperative real components with something that makes it easier to control

the indirect inputs and to verify the indirect outputs.

As we have seen, to test the indirect inputs, we must be able to control the

DOC well enough to cause it to return every possible kind of return value

(valid, invalid, and exception). To test indirect outputs, we must be able to track

the calls the SUT makes to other components. A Test Double is a type of object

that is much more cooperative and lets us write tests the way we want to.

Types of Test Doubles

A Test Double is any object or component that we install in place of the real

component for the express purpose of running a test. Depending on the reason

why we are using it, a Test Double can behave in one of four ways (summarized

in Figure 11.8):

•ADummy Object (page 728) is a placeholder object that is passed to

the SUT as an argument (or an attribute of an argument) but is never

actually used.

•ATest Stub is an object that replaces a real component on which the

SUT depends so that the test can control the indirect inputs of the SUT.

It allows the test to force the SUT down paths it might not otherwise

exercise. A Test Spy, which is a more capable version of a Test Stub,

can be used to verify the indirect outputs of the SUT by giving the test a

way to inspect them after exercising the SUT.

•AMock Object is an object that replaces a real component on which

the SUT depends so that the test can verify its indirect outputs.

Testing with Doubles

134

Chapter 11 Using Test Doubles

•AFake Object (page 551) (or just “Fake” for short) is an object that

replaces the functionality of the real DOC with an alternative imple-

mentation of the same functionality.

Figure 11.8 Several kinds of Test Doubles exist. Dummy Objects are really an

alternative to the value patterns. Test Stubs are used to verify indirect inputs;

Test Spies and Mock Objects are used to verify indirect outputs. Fake objects

emulate the behavior of the real depended-on component, but with test-friendly

characteristics.

Dummy Objects

Dummy Objects are a degenerate form of Test Double. They exist solely so

that they can be passed around from method to method; they are never used.

That is, Dummy Objects are not expected to do anything except exist. Often,

we can get away with using “null” (or “nil” or “nothing”); at other times,

we may be forced to create a real object because the code expects something

non-null. In dynamically typed languages, almost any real object will do; in

statically typed languages, we must make sure that the Dummy Object is

“type-compatible” with the parameter it is being passed as or the variable to

which it is being assigned.

In the following example, we pass an instance of DummyCustomer to the Invoice

constructor to satisfy a mandatory argument. We do not expect the DummyCustomer

to be used by the code we are testing here.

Configurable

Test Double

Test

Double

Mock

Object

Test

Spy

Dummy

Object

Test

Stub

Fake

Object

Hard-Coded

Test Double

Configurable

Test Double

Test

Double

Mock

Object

Test

Spy

Dummy

Object

Test

Stub

Fake

Object

Hard-Coded

Test Double

135

public void testInvoice_addLineItem_DO() {

ﬁnal int QUANTITY = 1;

Product product = new Product("Dummy Product Name",

getUniqueNumber());

Invoice inv = new Invoice( new DummyCustomer() );

LineItem expItem = new LineItem(inv, product, QUANTITY);

// Exercise

inv.addItemQuantity(product, QUANTITY);

// Verify

List lineItems = inv.getLineItems();

assertEquals("number of items", lineItems.size(), 1);

LineItem actual = (LineItem)lineItems.get(0);

assertLineItemsEqual("", expItem, actual);

}

Note that a Dummy Object is not the same as a Null Object [PLOPD3]. A

Dummy Object is not used by the SUT, so its behavior is irrelevant. By contrast,

a Null Object is used by the SUT but is designed to do nothing. That’s a small

but very important distinction!

Dummy Objects are in a different league than the other Test Doubles;

they are really an alternative to the attribute value patterns such as Literal

Value (page 714), Generated Value (page 723), and Derived Value (page 718).

Therefore, we don’t need to “conﬁ gure” them or “install” them. In fact, almost

nothing we say about the other Test Doubles applies to Dummy Objects, so we

won’t mention them again in this chapter.

Test Stubs

A Test Stub is an object that acts as a control point to deliver indirect

inputs to the SUT when the Test Stub’s methods are called. Its use allows us to

exercise Untested Code paths in the SUT that might otherwise be impossible to

traverse during testing. A Responder (see Test Stub) is a basic Test Stub that is

used to inject valid and invalid indirect inputs into the SUT via normal returns

from method calls. A Saboteur (see Test Stub) is a special Test Stub that raises

exceptions or errors to inject abnormal indirect inputs into the SUT. Because

procedural programming languages do not support objects, they force us to use

Procedural Test Stubs (see Test Stub).

In the following example, the Saboteur—implemented as an anonymous

inner class in Java—throws an exception when the SUT calls the getTime method

to allow us to verify that the SUT behaves correctly in this case:

public void testDisplayCurrentTime_exception()

throws Exception {

// Fixture setup

Testing with Doubles

136

Chapter 11 Using Test Doubles

// Deﬁne and instantiate Test Stub

TimeProvider testStub = new TimeProvider()

{ // Anonymous inner Test Stub

public Calendar getTime() throws TimeProviderEx {

throw new TimeProviderEx("Sample");

}

};

// Instantiate SUT

TimeDisplay sut = new TimeDisplay();

sut.setTimeProvider(testStub);

// Exercise SUT

String result = sut.getCurrentTimeAsHtmlFragment();

// Verify direct output

String expectedTimeString =

"<span class=\"error\">Invalid Time</span>";

assertEquals("Exception", expectedTimeString, result);

}

In procedural programming languages, a Procedural Test Stub is either (1) a

Test Stub implemented as a stand-in for an as-yet-unwritten procedure or (2) an

alternative implementation of a procedure linked into the program instead of

the real implementation of the procedure. Traditionally, Procedural Test Stubs

are introduced to allow debugging to proceed while we are waiting for other

code to be ready. They are rarely “swapped in” at runtime—this is hard to do

in most procedural languages. If we do not mind introducing Test Logic in Pro-

duction (page 217) code, we can implement a Procedural Test Stub using Test

Hooks (page 709) such as if testing then ... else in the SUT. This is illustrated

in the following listing:

public Calendar getTime() throws TimeProviderEx {

Calendar theTime = new GregorianCalendar();

if (TESTING) {

theTime.set(Calendar.HOUR_OF_DAY, 0);

theTime.set(Calendar.MINUTE, 0);}

else {

// just return the calendar

}

return theTime;

};

The key exception occurs in languages that support procedure variables.

These

variables allow us to implement dynamic binding as long as the client code ac-

cesses the procedure to be replaced via a procedure variable.

Also called function pointers.

137

Test Spies

A Test Spy is an object that can act as an observation point for the indirect

outputs of the SUT. To the capabilities of a Test Stub, it adds the ability to

quietly record all calls made to its methods by the SUT. The veriﬁ cation part

of the test performs Procedural Behavior Veriﬁ cation on those calls by using

a series of assertions to compare the actual calls received by the Test Spy with

the expected calls.

The following example uses the Retrieval Interface (see Test Spy) on the Test

Spy to verify that the correct information was passed as arguments in the call to the

logMessage method by the SUT (the removeFlight method of the facade).

public void testRemoveFlightLogging_recordingTestStub()

throws Exception {

// Fixture setup

FlightDto expectedFlightDto = createAnUnregFlight();

FlightManagementFacade facade =

new FlightManagementFacadeImpl();

// Test Double setup

AuditLogSpy logSpy = new AuditLogSpy();

facade.setAuditLog(logSpy);

// Exercise

facade.removeFlight(expectedFlightDto.getFlightNumber());

// Verify state

assertFalse("ﬂight still exists after being removed",

facade.ﬂightExists( expectedFlightDto.

getFlightNumber()));

// Verify indirect outputs using retrieval interface of spy

assertEquals("number of calls", 1,

logSpy.getNumberOfCalls());

assertEquals("action code",

Helper.REMOVE_FLIGHT_ACTION_CODE,

logSpy.getActionCode());

assertEquals("date", helper.getTodaysDateWithoutTime(),

logSpy.getDate());

assertEquals("user", Helper.TEST_USER_NAME,

logSpy.getUser());

assertEquals("detail",

expectedFlightDto.getFlightNumber(),

logSpy.getDetail());

}

Mock Objects

A Mock Object is also an object that can act as an observation point for the

indirect outputs of the SUT. Like a Test Stub, it may need to return information

in response to method calls. Also like a Test Spy, a Mock Object pays attention

to how it was called by the SUT. It differs from a Test Spy, however, in that the

Testing with Doubles