Meszaros G. xUnit Test Patterns Refactoring Test Code

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

Chapter 8 Transient Fixture Management

Most Fresh Fixtures we build are transient, so we will cover that case ﬁ rst.

We will then come back to managing Persistent Fresh Fixtures in Chapter 9.

Building Fresh Fixtures

Whether we are building a Transient Fresh Fixture or a Persistent Fresh Fixture,

the choices we have for how to construct it are pretty much the same. The ﬁ xture

setup logic includes the code needed to instantiate the SUT,

the code to put the SUT

into the appropriate starting state, and the code to create and initialize the state of

anything the SUT depends on or that will be passed to it as an argument. The most

obvious way to set up a Fresh Fixture is through In-line Setup (page 408), in which

all ﬁ xture setup logic is contained within the Test Method. This type of ﬁ xture can

also be constructed by using Delegated Setup (page 411), which involves calling

Test Utility Methods (page 599). Finally, we can use Implicit Setup (page 424),

in which the Test Automation Framework (page 298) calls a special

setUp method

we provide on our Testcase Class. We can also use a combination of these three

approaches. Let’s look at each possibility individually.

In-line Fixture Setup

In In-line Setup, the test handles all of the fixture setup within the body of

the Test Method. We construct objects, call methods on them, construct the

SUT, and call methods on it to put into a specific state. We perform all of

these tasks from within our Test Method. Think of In-line Setup as the do-

it-yourself approach to fixture creation.

public void testStatus_initial() {

// In-line setup

Airport departureAirport = new Airport("Calgary", "YYC");

Airport destinationAirport = new Airport("Toronto", "YYZ");

Flight ﬂight = new Flight( ﬂightNumber,

departureAirport,

destinationAirport);

// Exercise SUT and verify outcome

assertEquals(FlightState.PROPOSED, ﬂight.getStatus());

// tearDown:

// Garbage-collected

}

This discussion assumes that the SUT is an object and not just static methods on a

class.

The main drawback of In-line Setup is that it tends to lead to Test Code Dupli-

cation (page 213) because each Test Method needs to construct the SUT. Many

of the Test Methods also need to perform similar ﬁ xture setup. This Test Code

Duplication leads, in turn, to High Test Maintenance Cost (page 265) caused

by Fragile Tests (page 239). If the work to create the ﬁ xture is complex, it can

also lead to Obscure Tests (page 186). A related problem is that In-line Setup

tends to encourage Hard-Coded Test Data (see Obscure Test) within each Test

Method because creating a local variable with an Intent-Revealing Name [SBPP]

may seem like too much work for the beneﬁ t yielded.

We can prevent these test smells by moving the code that sets up the ﬁ xture

out of the Test Method. The location where we move it determines which of the

alternative ﬁ xture setup strategies we have used.

Delegated Fixture Setup

A quick and easy way to reduce Test Code Duplication and the resulting Obscure

Tests is to refactor our Test Methods to use Delegated Setup. We can use an Extract

Method [Fowler] refactoring to move a sequence of statements used in several Test

Methods into a Test Utility Method that we then call from those Test Methods. This

is a very simple and safe refactoring, especially when we let the IDE do all the heavy

lifting for us. When the extracted method contains logic to create an object on which

our test depends, we call it a Creation Method (page 415). Creation Methods

with

Intent-Revealing Names make the test’s pre-conditions readily apparent to the reader

while avoiding unnecessary Test Code Duplication. They allow both the test reader

and the test automater to focus on what is being created without being distracted

by how it is created. The Creation Methods act as reusable building blocks for test

ﬁ xture construction.

public void testGetStatus_inital() {

// Setup

Flight ﬂight = createAnonymousFlight();

// Exercise SUT and verify outcome

assertEquals(FlightState.PROPOSED, ﬂight.getStatus());

// Teardown

// Garbage-collected

}

One goal of these Creation Methods is to eliminate the need for every test

to know the details of how the objects it requires are created. This stream-

lining goes a long way toward preventing Fragile Tests caused by changes to

When referenced via a Test Helper (page 643) class, they are often called the Object

Mother pattern (see Test Helper on page 643).

Building Fresh Fixtures

Chapter 8 Transient Fixture Management

constructor method signatures or semantics. When a test does not care about

the speciﬁ c identity of the objects it is creating, we can use Anonymous Cre-

ation Methods (see Creation Method). These methods generate any unique keys

required by the object being created. By using a Distinct Generated Value (see

Generated Value on page 723), we can guarantee that no other test instance

that requires a similar object will accidentally use the same object as this test.

This safeguard prevents many forms of the behavior smell Erratic Test, includ-

ing Unrepeatable Tests, Interacting Tests, and Test Run Wars, even if we hap-

pen to be using a persistent object repository that supports Shared Fixtures.

When a test does care about the attributes of the object being created, we

use a Parameterized Anonymous Creation Method (see Creation Method). This

method is passed any attributes that the test cares about (i.e., attributes that are

important to the test outcome), leaving all other attributes to be defaulted by the

implementation of the Creation Method. My motto is this:

When it is not important for something to be seen in the test method,

it is important that it not be seen in the test method!

Delegated Setup is often used when we write input validation tests for

SUT methods that are expected to validate the attributes of an object argu-

ment. In such a case, we need to write a separate test for each invalid at-

tribute that should be detected. Building all of these slightly invalid objects

would be a lot of work using In-line Setup. We can reduce the effort and

the amount of Test Code Duplication dramatically by using the pattern

One Bad Attribute (see Derived Value on page 718). That is, we first call

a Creation Method to create a valid object, and then we replace one attri-

bute with an invalid value that should be rejected by the SUT. Similarly, we

might create an object in the correct state by using a Named State Reaching

Method (see Creation Method).

Some people prefer to Reuse Tests for Fixture Setup (see Creation Method) as an

alternative to using Chained Tests (page 454). That is, they call other tests directly

within the setup portion of their test. This approach is not an unreasonable one as

long as the test reader can readily identify what the other test is setting up for the

current test. Unfortunately, very few tests are named in such a way as to convey this

intention. For this reason, if we value Tests as Documentation, we will want to con-

sider wrapping the called test with a Creation Method that has an Intent-Revealing

Name so that test reader can get a sense of what the ﬁ xture looks like.

The Creation Methods can be kept as private methods on the Testcase

Class, pulled up to a Testcase Superclass (page 638), or moved to a Test Help-

er (page 643). The “mother of all creation methods” is Object Mother (see Test

Helper). This strategy-level pattern describes a family of approaches that center

on the use of Creation Methods on one or more Test Helpers and may include

Automated Teardown (page 503) as well.

Implicit Fixture Setup

Most members of the xUnit family provide a convenient hook for calling code

that needs to be run before every Test Method. Some members call a method

with a speciﬁ c name (e.g., setUp). Others call a method that has a speciﬁ c annota-

tion (e.g., “@before” in JUnit) or method attribute (e.g., “[Setup]” in NUnit). To

avoid repeating these alternative ways every time we need to refer to this mecha-

nism, this book simply calls it the setUp method regardless of how we indicate

this fact to the Test Automation Framework. The setUp method is optional or an

empty default implementation is provided by the framework, so we do not have

to provide one in each Testcase Class.

In Implicit Setup, we take advantage of this framework “hook” by putting all

of the ﬁ xture creation logic into the setUp method. Because every Test Method on

the Testcase Class shares this ﬁ xture setup logic, all Test Methods need to be able

to use the ﬁ xture it creates. This tactic certainly addresses the Test Code Duplica-

tion problem but it does have several consequences. What does the following test

actually verify?

Airport departureAirport;

Airport destinationAirport;

Flight ﬂight;

public void testGetStatus_inital() {

// Implicit setup

// Exercise SUT and verify outcome

assertEquals(FlightState.PROPOSED, ﬂight.getStatus());

}

The ﬁ rst consequence is that this approach can make the tests more difﬁ cult to

understand because we cannot see how the pre-conditions of the test (the test

ﬁ xture) correlate with the expected outcome within the Test Method; we have to

look in the setUp method to see this relationship.

public void setUp() throws Exception{

super.setUp();

departureAirport = new Airport("Calgary", "YYC");

destinationAirport = new Airport("Toronto", "YYZ");

BigDecimal ﬂightNumber = new BigDecimal("999");

ﬂight = new Flight( ﬂightNumber , departureAirport,

destinationAirport);

}

Building Fresh Fixtures

Chapter 8 Transient Fixture Management

We can mitigate this problem by naming our Testcase Class based on the test

ﬁ xture created in the setUp method. Of course, this makes sense only if all of the

Test Methods really need the same ﬁ xture—it is an example of Testcase Class per

Fixture (page 631). As mentioned earlier, several members of the xUnit family

(VbUnit and NUnit, to name two) use the term “test ﬁ xture” to describe what

this book calls the Testcase Class. This nomenclature is probably based on the

assumption that we are using a Testcase Class per Fixture strategy.

Another consequence of using Implicit Setup is that we cannot use local vari-

ables to hold references to the objects in our ﬁ xture. Instead, we are forced to

use instance variables to refer to any objects that are constructed in the setUp

method and that are needed either when exercising the SUT, when verifying

the expected outcome, or when tearing down the ﬁ xture. These instance vari-

ables act as global variables between the parts of the test. As long as we stick

to instance variables rather than class variables, however, the test ﬁ xture will

be newly constructed for each test case in the Testcase Class. Most members

of xUnit provide isolation between the ﬁ xture created for each Test Method

but at least one (NUnit) does not; see the sidebar “There’s Always an Excep-

tion” (page 384) for more information. In any event, we should deﬁ nitely give

the variables Intent-Revealing Names so that we do not need to keep referring

back to the setUp method to understand what they hold.

Misuse of the SetUp Method

When you have a new hammer, everything looks like a nail!

Like any feature of any system, the setUp method can be abused. We should

not feel obligated to use it just because it is provided. It is one of several code

reuse mechanisms that are available for our application. When object-oriented

languages were ﬁ rst introduced, programmers were enamored with inheritance

and tried to apply it in all possible reuse scenarios. Over time, we learned when

inheritance was appropriate and when we should resort to other mechanisms

such as delegation. The setUp method is xUnit’s inheritance.

The setUp method is most prone to misuse when it is applied to build a Gen-

eral Fixture (see Obscure Test) with multiple distinct parts, each of which is

dedicated to a different Test Method. This can lead to Slow Tests (page 253)

if we are building a Persistent Fresh Fixture. More importantly, it can lead to

Obscure Tests by hiding the cause–effect relationship between the ﬁ xture and

the expected outcome of exercising the SUT.

If we do not adopt the practice of grouping the Test Methods into Testcase

Classes based on identical ﬁ xtures but we do use the setUp method, we should

build only the lowest common denominator part of the ﬁ xture in the setUp

method. That is, only the setup logic that will not cause problems in any of

the tests should be placed in the setUp method. Even the ﬁ xture setup code

that does not cause problems for any of the Test Methods can still cause other

problems if we use the setUp method to build a General Fixture instead of a

Minimal Fixture (page 302). A General Fixture is a common cause of Slow

Tests because each test spends much more time than necessary building the

test ﬁ xture. It also tends to produce Obscure Tests because the test reader

cannot easily see which part of the ﬁ xture a particular Test Method depends

on. A General Fixture often evolves into a Fragile Fixture (see Fragile Test)

as the relationship between its various elements and the tests that use them

is forgotten over time. Changes made to the ﬁ xture to support a newly added

test may then cause existing tests to fail.

Note that if we use a class variable to hold the object, we may have crossed

the line into the world of Persistent Fresh Fixtures. Use of Lazy Setup (page 435)

to populate the variable, by contrast, carries us into the world of Shared Fix-

tures because later tests within the test suite may reuse the object(s) created

in earlier tests and thus may become dependent on the changes the other test

(should have) made to it.

Hybrid Fixture Setup

This chapter has presented the three styles of ﬁ xture construction as strict alter-

natives to one another. In practice, there is value in combining them. Test auto-

maters often call some Creation Methods from within the Test Method but then

do some additional setup on an in-line basis. The readability of the setUp method

can also be improved if it calls Creation Methods to construct the ﬁ xture. An

additional beneﬁ t is that the Creation Methods can be unit-tested much more

easily than either in-line ﬁ xture construction logic or the setUp method. These

methods can also be located on a class outside the Testcase Class hierarchy such

as a Test Helper.

Tearing Down Transient Fresh Fixtures

One really nice thing about Transient Fresh Fixtures is that ﬁ xture teardown requires

very little effort. Most members of the xUnit family are implemented in languages

that support garbage collection. As long as our references to the ﬁ xture are held in

variables that go out of scope, we can count on Garbage-Collected Teardown to do

all the work for us. See the sidebar “There’s Always an Exception” on page 384 for

a description of why the same is not true in NUnit.

Tearing Down Transient Fresh Fixtures

Chapter 8 Transient Fixture Management

If we are using one of the few members of the xUnit family that does not sup-

port garbage collection, we may have to treat all Fresh Fixtures as persistent.

What’s Next?

This chapter introduced techniques for setting up and tearing down an in-memory

Fresh Fixture. With some planning and a bit of luck, they are all you should need for

the majority of your tests. Managing Fresh Fixtures is more complicated when the

ﬁ xture is persisted either by the SUT or by the test itself. Chapter 9, Persistent Fixture

Management, introduces additional techniques needed for managing persistent ﬁ x-

tures, including Persistent Fresh Fixtures and Shared Fixtures.

Chapter 9

Persistent Fixture

Management

About This Chapter

In Chapter 8, Transient Fixture Management, we saw how we can go about

building in-memory Fresh Fixtures (page 311). We noted in that chapter that

managing Fresh Fixtures is more complicated when the ﬁ xture is persisted either

by the SUT or by the test itself. This chapter introduces the additional patterns

required to manage persistent ﬁ xtures, including both Persistent Fresh Fixtures

(see Fresh Fixture) and Shared Fixtures (page 317).

Managing Persistent Fresh Fixtures

The term Persistent Fresh Fixture might sound like an oxymoron but it is

actually not as large a contradiction as it might ﬁ rst seem. The Fresh Fixture strat-

egy means that each run of each Test Method (page 348) uses a newly created ﬁ x-

ture. The name speaks to its intent: We do not reuse the ﬁ xture! It does not need

to imply that the ﬁ xture is transient—only that it is not reused (Figure 9.1). Per-

sistent Fresh Fixtures present several challenges not encountered with Transient

Fresh Fixtures. In this chapter, we focus on the challenge posed by Unrepeatable

Tests (see Erratic Test on page 228) caused by leftover Persistent Fresh Fixtures

and Slow Tests (page 253) caused by Shared Fixtures (page 317).

What Makes Fixtures Persistent?

A ﬁ xture, fresh or otherwise, can become persistent for one of two reasons. The

ﬁ rst reason is that the SUT is a stateful object and “remembers” how it was used

in the past. This scenario most often occurs when the SUT includes a database,

Chapter 9 Persistent Fixture Management

Figure 9.1 A Fresh Fixture can be either transient or persistent. We can apply a

Fresh Fixture strategy even if the test ﬁ xture is naturally persistent but we must

have a way to tear it down after each test.

but it can occur simply because the SUT uses class variables to hold some of its

data. The second reason is that the Testcase Class (page 373) holds a reference

to an otherwise Transient Fresh Fixture in a way that makes it survive across

Test Method invocations.

Some members of the xUnit family provide a mechanism to reload all classes

at the beginning of each test run. This behavior may appear as an option—a

check box labeled “Reload Classes”—or it may be automatic. Such a feature

keeps the ﬁ xture from becoming persistent when it is referenced from a class

variable; it does not prevent the Fresh Fixture from becoming persistent if either

the SUT or the test puts the ﬁ xture into the ﬁ le system or a database.

Issues Caused by Persistent Fresh Fixtures

When ﬁ xtures are persistent, we may ﬁ nd that subsequent runs of the same Test

Method try to recreate a ﬁ xture that already exists. This behavior may cause

conﬂ icts between the preexisting and newly created resources. Although violat-

ing unique key constraints in the database is the most common example of this

problem, the conﬂ ict could be as simple as trying to create a ﬁ le with the same

name as one that already exists. One way to avoid these Unrepeatable Tests is

to tear down the ﬁ xture at the end of each test; another is to use Distinct Gen-

erated Values (see Generated Value on page 723) for any identiﬁ ers that might

cause conﬂ icts.

Transient

Persistent

Immutable

Shared

Fixture

Shared

Fixture

Fresh

Fixture

Transient

Persistent

Immutable

Shared

Fixture

Shared

Fixture

Fresh

Fixture

Tearing Down Persistent Fresh Fixtures

Unlike ﬁ xture setup code, which should help us understand the pre-conditions

of the test, ﬁ xture teardown code is purely a matter of good housekeeping. It

does not help us understand the behavior of the SUT but it has the potential to

obscure the intent of the test or at least make it more difﬁ cult to understand.

Therefore, the best kind of teardown code is the nonexistent kind. We should

avoid writing teardown code whenever we can, which is why Garbage-Collected

Teardown (page 500) is so preferable. Unfortunately, we cannot take advantage

of Garbage-Collected Teardown if our Fresh Fixture is persistent.

Hand-Coded Teardown

One way to ensure that the ﬁ xture is destroyed after we are done with it is to

include test-speciﬁ c teardown code within our Test Methods. This teardown

mechanism might seem simple, but it is actually more complex than immediately

meets the eye. Consider the following example:

public void testGetFlightsByOriginAirport_NoFlights()

throws Exception {

// Fixture Setup

BigDecimal outboundAirport = createTestAirport("1OF");

// Exercise System

List ﬂightsAtDestination1 =

facade.getFlightsByOriginAirport(outboundAirport);

// Verify Outcome

assertEquals(0,ﬂightsAtDestination1.size());

facade.removeAirport(outboundAirport);

}

This Naive In-line Teardown (see In-line Teardown on page 509) will tear down

the ﬁ xture when the test passes—but it won’t tear down the ﬁ xture if the test

fails or ends with an error. This is because the calls to the Assertion Meth-

ods (page 362) throw an exception; therefore, we may never make it to the

teardown code. To ensure that the In-line Teardown code always executes, we

must surround everything in the Test Method that might raise an exception with

a try/catch control structure. Here’s the same test suitably modiﬁ ed:

public void testGetFlightsByOriginAirport_NoFlights_td()

throws Exception {

// Fixture Setup

BigDecimal outboundAirport = createTestAirport("1OF");

try {

// Exercise System

List ﬂightsAtDestination1 =

facade.getFlightsByOriginAirport(outboundAirport);

Managing Persistent Fresh Fixtures