Meszaros G. xUnit Test Patterns Refactoring Test Code

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

148

Chapter 11 Using Test Doubles

Other Ways of Retroﬁ tting Testability

All is not lost when none of the techniques described thus far can be used to

introduce testability. We still have a few tricks left up our sleeves.

Test Hooks are the “elephant in the room” that no one wants to talk about

because they may lead to Test Logic in Production. Test Hooks, however, are

a perfectly legitimate way to get legacy code under test when it is too hard or

dangerous to introduce one of the techniques described earlier. They are best

used as a “transition” strategy to allow Scripted Tests (page 285) or Recorded

Tests (page 278) to be automated to provide a Safety Net (see page 24) while

large-scale refactoring is undertaken to improve testability. Ideally, once the

code has been made more testable, better tests can be prepared using the tech-

niques described earlier and the Test Hooks can be removed.

Michael Feathers [WEwLC] has described several other techniques to

replace dependencies with test-speciﬁ c code under the general heading of ﬁ nd-

ing “object seams.” For example, we can replace a depended-on library with

a library designed speciﬁ cally for testing. A seemingly hard-coded dependency

can be broken this way. Most of these techniques are less applicable when we

need to dynamically replace dependencies within individual tests than either

Dependency Injection or Dependency Lookup because they require changes to

the environment. Object seams are, however, an excellent way to place legacy

code under test so that it can be refactored to introduce either of the previously

mentioned dependency-breaking techniques.

We can use aspect-oriented programming (AOP) to install the Test

Double behavior by deﬁ ning a test point-cut that matches the place where

the SUT calls the DOC and we would rather have it call the Test Double.

Although we need an AOP-enabled development environment to do this, we

do not need to deploy the AOP-generated code into a production environ-

ment. As a consequence, this technique may be used even in AOP-hostile

environments.

Other Uses of Test Doubles

So far, we have covered the testing of indirect inputs and indirect outputs. Now

let’s look at some other uses of Test Doubles.

149

Endoscopic Testing

Tim Mackinnon et al. introduced the concept of endoscopic testing [ET] in their

initial Mock Objects paper. Endoscopic testing focuses on testing the SUT from

the inside by passing in a Mock Object as an argument to the method under test.

This allows veriﬁ cation of certain internal behaviors of the SUT that may not

always be visible from the outside.

The classic example that Mackinnon and colleagues cite is the use of a mock

collection class preloaded with all of the expected members of the collection.

When the SUT tries to add an unexpected member, the mock collection’s asser-

tion fails. The full stack trace of the internal call stack then becomes visible in

the xUnit failure report. If our IDE supports breaking on speciﬁ ed exceptions,

we can also inspect the local variables at the point of failure.

Need-Driven Development

A reﬁ nement of endoscopic testing is “need-driven development” [MRNO], in

which the dependencies of the SUT are deﬁ ned as the tests are written. This

“outside-in” approach to writing and testing software combines the conceptual

elegance of the traditional “top-down” approach to writing code with modern

TDD techniques supported by Mock Objects. It allows us to build and test the

software layer by layer, starting at the outermost layer before we have imple-

mented the lower layers.

Need-driven development combines the beneﬁ ts of test-driven development

(specifying all software with tests before we build them) with a highly incre-

mental approach to design that removes the need for any speculation about

how a depended-on class might be used.

Speeding Up Fixture Setup

Another application of Test Doubles is to reduce the runtime cost of Fresh Fix-

ture (page 311) setup. When the SUT needs to interact with other objects that

are difﬁ cult to create because they have many dependencies, a single Test Dou-

ble can be created instead of the complex network of objects. When applied to

networks of entity objects, this technique is called Entity Chain Snipping (see

Test Stub).

Other Uses of Test Doubles

150

Chapter 11 Using Test Doubles

Speeding Up Test Execution

Test Doubles may also be used to speed up tests by replacing slow compo-

nents with faster ones. Replacing a relational database with an in-memory Fake

Object, for example, can reduce test execution times by an order of magnitude!

The extra effort required to code the Fake Database is more than offset by the re-

duced waiting time and the quality improvement due to the more timely feedback

that comes from running the tests more frequently. Refer to the sidebar “Faster

Tests without Shared Fixtures” on page 319 for a more detailed discussion of

this issue.

Other Considerations

Because many of our tests will involve replacing a real DOC with a Test

Double, how do we know that the production code will work properly when

it uses the real DOC? Of course, we would expect our customer tests to verify

behavior with the real DOCs in place (except, possibly, when the real DOCs are

interfaces to other systems that need to be stubbed out during single-system

testing). We should write a special form of Constructor Test (see Test Method)—

a “substitutable initialization test”—to verify that the real DOC is installed

properly. The trigger for writing this test is performing the ﬁ rst test that

replaces the DOC with a Test Double—that point is often when the Test

Double installation mechanism is introduced.

Finally, we want to be careful that we don’t fall into the “new hammer

trap.”

Overuse of Test Doubles (and especially Mock Objects or Test Stubs) can

lead to Overspeciﬁ ed Software (see Fragile Test on page 239) by encoding

implementation-speciﬁ c information about the design in our tests. The design

may be then much more difﬁ cult to change if many tests are affected by the

change simply because they use a Test Double that has been affected by the

design change.

“When you have a new hammer, everything looks like a nail.”

151

What’s Next?

In this chapter, we examined techniques for testing software with indirect inputs

and indirect outputs. In particular, we explored the concept of Test Doubles

and various techniques for installing them. In Chapter 12, Organizing Our

Tests, we will turn our attention to strategies for organizing the test code into

Test Methods and Test Utility Methods (page 599) implemented on Testcase

Classes (page 373) and Test Helpers (page 643).

What’s Next?

This page intentionally left blank

153

Chapter 12

Organizing Our Tests

About This Chapter

In the chapters concluding with Chapter 11, Using Test Doubles, we looked at

various techniques for interacting with the SUT for the purpose of verifying its

behavior. In this chapter, we turn our attention to the question of how to orga-

nize the test code to make it easy to ﬁ nd and understand.

The basic unit of test code organization is the Test Method (page 348).

Deciding what to put in the Test Method and where to put it is central to the topic

of test organization. When we have only a few tests, how we organize them isn’t

terribly important. By contrast, when we have hundreds of tests, test organization

becomes a critical factor in keeping our tests easy to understand and ﬁ nd.

This chapter begins by discussing what we should and should not include in

a Test Method. Next, it explores how we can decide on which Testcase Classes

(page 373) to put our Test Methods. Test naming depends heavily on how we

have organized our tests, so we will talk about this issue next. We will then

consider how to organize the Testcase Classes into test suites and where to put

test code. The ﬁ nal topic is test code reuse—speciﬁ cally, where to put reusable

test code.

Basic xUnit Mechanisms

The xUnit family of Test Automation Frameworks (page 298) provides a num-

ber of features to help us organize our tests. The basic question, “Where do I

code my tests?”, is answered by putting our test code into a Test Method on a

Testcase Class. We then use either Test Discovery (page 393) or Test Enumera-

tion (page 399) to create a Test Suite Object (page 387) containing all the tests

from the Testcase Class. The Test Runner (page 377) invokes a method on the

Test Suite Object to run all the Test Methods.

154

Chapter 12 Organizing Our Tests

Right-Sizing Test Methods

A test condition is something we need to prove the SUT really does; it can be

described in terms of what the starting state of the SUT is, how we exercise the

SUT, how we expect the SUT to respond, and what the ending state of the SUT

is expected to be. A Test Method is a sequence of statements in our test scripting

language that exercises one or more test conditions (Figure 12.1). What should

we include in a single Test Method?

Figure 12.1 The four phases of a typical test. Each Test Method implements a

Four-Phase Test (page 358) that ideally veriﬁ es a single test condition. Not all

phases of the Four-Phase Test need be in the Test Method.

Many xUnit purists prefer to Verify One Condition per Test (see page 45)

because it gives them good Defect Localization (see page 22). That is, when a

test fails, they know exactly what is wrong in the SUT because each test veriﬁ es

exactly one test condition. This is very much in contrast with manual testing,

where one tends to build long, involved multiple-condition tests because of the

overhead involved in setting up each test’s pre-conditions. When creating xUnit-

based automated tests, we have many ways of dealing with this frequently re-

peated ﬁ xture setup (as described in Chapter 8, Transient Fixture Management),

so we tend to Verify One Condition per Test. We call a test that veriﬁ es too many

test conditions an Eager Test (see Assertion Roulette on page 224) and consider

it a code smell.

A test that veriﬁ es a single test condition executes a single code path through

the SUT and it should execute exactly the same path each time it runs; that

is what makes it a Repeatable Test (see page 26). Yes, that means we need as

Testcase

Class

Create

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

testMethod_n

Test

Suite

Object

Exercise

Create

Exercise

Create

Fixture

SUT

Run

Suite

Test Runner

Setup

Exercise

Verify

Teardown

Testcase

Class

Create

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

testMethod_n

Test

Suite

Object

Exercise

Create

Exercise

Create

Fixture

SUT

Run

Suite

Test Runner

Setup

Exercise

Verify

Teardown

155

many test methods as we have paths through the code—but how else can we

expect to achieve full code coverage? What makes this pattern manageable is

that we Isolate the SUT (see page 43) when we write unit tests for each class so

we only have to focus on paths through a single object. Also, because each test

should verify only a single path through the code, each test method should con-

sist of strictly sequential statements that describe what should happen on that

one path.

Another reason we Verify One Condition per Test (see page 45) is to

Minimize Test Overlap (see page 44) so that we have fewer tests to modify if we

later modify the behavior of the SUT.

Brian Marrick has developed an interesting compromise that I call “While

We’re at It,”

which leverages the test ﬁ xture we already have set up to run

some additional checks and assertions. Marrick clearly marks these elements

with comments to indicate that if changes to the SUT obsolete that part of the

test, they can be easily deleted. This strategy minimizes the effort needed to

maintain the extra test code.

Test Methods and Testcase Classes

A Test Method needs to live on a Testcase Class. Should we put all our Test

Methods onto a single Testcase Class for the application? Or should we create a

Testcase Class for each Test Method? Of course, the right answer lies somewhere

between these two extremes, and it will change over the life of our project.

Testcase Class per Class

When we write our ﬁ rst few Test Methods, we can put them all onto a single

Testcase Class. As the number of Test Methods increases, we will likely want to

split the Testcase Class so that one Testcase Class per Class (page 617) is tested,

which reduces the number of Test Methods per class (Figure 12.2). As those

Testcase Classes get too big, we usually split the classes further. In that case, we

need to decide which Test Methods to include in each Testcase Class.

A Test Method that contains Conditional Test Logic (page 200) is a sign of a test trying

to accommodate different circumstances because it does not have control of all indirect

inputs of the SUT or because it is trying to verify complex expected states on an in-line

basis within the Test Method.

He calls it “Just for Laughs” but I don’t ﬁ nd that name very intent-revealing.

Test Methods and Testcase Classes

156

Chapter 12 Organizing Our Tests

Figure 12.2 A production class with a single Testcase Class. With the Testcase

Class per Class pattern, a single Testcase Class holds all the Test Methods for

all the behavior of our SUT class. Each Test Method may need to create a

different ﬁ xture either in-line or by delegating that task to a Creation Method

(page 415).

Testcase Class per Feature

One school of thought is to put all Test Methods that verify a particular feature of

the SUT—where a “feature” is deﬁ ned as one or more methods and attributes that

collectively implement some capability of the SUT—into a single Testcase Class

(Figure 12.3). This makes it easy to see all test conditions for that feature. (Use of

appropriate Test Naming Conventions helps achieve this clarity.) It can, however,

result in similar ﬁ xture setup code being required in each Testcase Class.

Testcase Class per Fixture

The opposing view is that one should group all Test Methods that require the same

test ﬁ xture (same pre-conditions) into one Testcase Class per Fixture (page 631; see

Figure 12.4). This facilitates putting the test ﬁ xture setup code into the setUp method

(Implicit Setup; see page 424) but can result in scattering of the test conditions for

each feature across many Testcase Classes.

TestcaseClass

Fixture B

Fixture A

SUT Class

testMethod_B_1

testMethod_B_2

testMethod_A_1

testMethod_A_2

feature_1

feature_2

Exercise

Creation

TestcaseClass

Fixture B

Fixture A

SUT Class

testMethod_B_1

testMethod_B_2

testMethod_A_1

testMethod_A_2

feature_1

feature_2

Exercise

Creation

157

Figure 12.3 A production class with one Testcase Class for each feature. With

the Testcase Class per Feature pattern, we have one Testcase Class for each

major capability or feature supported by our SUT class. The Test Methods on

that test class exercise various aspects of that feature after building whatever test

ﬁ xture they require.

Figure 12.4 A production class with one Testcase Class for each ﬁ xture. With

the Testcase Class per Fixture pattern, we have one Testcase Class for each

possible test ﬁ xture (test pre-condition) of our SUT class. The Test Methods on

that test class exercise various features from the common starting point.

Fixture B

Fixture A

SUT Class

Feature2TestcaseClass

testMethod_A

testMethod_B

Feature1TestcaseClass

testMethod_A

testMethod_B

Creation

feature_1

feature_2

Creation

Exercise

Fixture B

Fixture A

SUT Class

Feature2TestcaseClass

testMethod_A

testMethod_B

Feature1TestcaseClass

testMethod_A

testMethod_B

Creation

feature_1

feature_2

Creation

Exercise

Fixture B

Fixture A

SUT Class

FixtureBTestcaseClass

testMethod_1

testMethod_2

FixtureATestcaseClass

testMethod_2

setUp

feature_1

feature_2

Creation

Exercise

FixtureATestcaseClass

testMethod_1

Fixture B

Fixture A

SUT Class

FixtureBTestcaseClass

testMethod_1

testMethod_2

FixtureATestcaseClass

testMethod_2

setUp

feature_1

feature_2

Creation

Exercise

FixtureATestcaseClass

testMethod_1

Test Methods and Testcase Classes