Meszaros G. xUnit Test Patterns Refactoring Test Code

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

When building a Standard Fixture for use as a Shared Fixture, we can employ

any of the Shared Fixture setup patterns including Suite Fixture Setup (page 441),

Lazy Setup (page 435), and Setup Decorator (page 447).

Motivating Example

As mentioned earlier, we are most likely to end up using a Standard Fixture

because we started that way—and we probably started that way as the result

of the background of one of the project participants. We probably would not

refactor our tests to use a Standard Fixture when those tests are already written

to use a Minimal Fixture unless we were refactoring to create a Testcase Class

per Fixture. For the sake of illustration, let’s assume that we did want to get to

“here” from “there.” The following example uses Creation Methods (page 415)

to build a custom Fresh Fixture for each test:

public void testGetFlightsByFromAirport_OneOutboundFlight_c()

throws Exception {

FlightDto outboundFlight = createOneOutboundFlightDto();

// Exercise System

List ﬂightsAtOrigin =

facade.getFlightsByOriginAirport(

outboundFlight.getOriginAirportId());

// Verify Outcome

assertOnly1FlightInDtoList( "Flights at origin",

outboundFlight,

ﬂightsAtOrigin);

}

public void testGetFlightsByFromAirport_TwoOutboundFlights_c()

throws Exception {

FlightDto[] outboundFlights =

createTwoOutboundFlightsFromOneAirport();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlights[0].getOriginAirportId());

// Verify Outcome

assertExactly2FlightsInDtoList( "Flights at origin",

outboundFlights,

ﬂightsAtOrigin);

}

To keep this test short, we have used Delegated Setup to populate the SUT with

the Minimal Fixture needed for each test. We could have included the ﬁ xture

setup code in-line in each method, but that choice would take us down the road

toward an Obscure Test.

Standard

Fixture

Chapter 18 Test Strategy Patterns

308

Refactoring Notes

Technically speaking, converting a pile of tests to a Standard Fixture isn’t really a

“refactoring” because we actually change the behavior of these tests. The biggest

challenge is designing the reusable Standard Fixture in such a way that each Test

Method can ﬁ nd some part of the ﬁ xture that serves its needs. This means synthe-

sizing all of the individual purpose-built Minimal Fixtures into a single “jack of

all trades” ﬁ xture. Not surprisingly, this reworking of the code can be a nontrivial

exercise when we have a lot of tests.

The easy and mechanical part of the refactoring is to convert the logic in

each test that constructs the ﬁ xture into calls to Finder Methods (see Test Utility

Method) that retrieve the appropriate part of the Standard Fixture. This transfor-

mation is most easily done as a series of steps. First, we extract the in-line ﬁ xture

construction logic in each Test Method into one or more Creation Methods with

Intent-Revealing Names [SBPP]. Next, we do a global replace on the “create” part

of each call to “ﬁ nd.” Finally, we generate (either manually or using our IDE’s

“quick ﬁ x” capability) the Finder Methods needed to get the calls to compile.

Inside each Finder Methods we add in code to return the relevant part of the

Standard Fixture.

Example: Standard Fixture

Here’s the example given earlier converted to use a Standard Fixture:

public void testGetFlightsByFromAirport_OneOutboundFlight()

throws Exception {

setupStandardAirportsAndFlights();

FlightDto outboundFlight = ﬁndOneOutboundFlight();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlight.getOriginAirportId());

// Verify Outcome

assertOnly1FlightInDtoList( "Flights at origin",

outboundFlight,

ﬂightsAtOrigin);

}

public void testGetFlightsByFromAirport_TwoOutboundFlights()

throws Exception {

setupStandardAirportsAndFlights();

FlightDto[] outboundFlights =

ﬁndTwoOutboundFlightsFromOneAirport();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlights[0].getOriginAirportId());

// Verify Outcome

Standard Fixture

Standard

Fixture

309

assertExactly2FlightsInDtoList( "Flights at origin",

outboundFlights,

ﬂightsAtOrigin);

}

To make the use of a Standard Fixture really obvious, this example shows a

Fresh Fixture that is created explicitly in each test by calling the same Creation

Method to set up the Standard Fixture (i.e., using Delegated Setup). We could

have achieved the same effect by putting the ﬁ xture construction logic into the

setUp method, thus using Implicit Setup. The resulting test would look identical

to one that uses a Shared Fixture.

Standard

Fixture

Chapter 18 Test Strategy Patterns

310

Fresh Fixture

Which ﬁ xture strategy should we use?

Each test constructs its own brand-new test ﬁ xture for its

own private use.

Every test needs a test ﬁ xture. It deﬁ nes the state of the test environment before

the test. The choice of whether to build the ﬁ xture from scratch each time the

test is run or to reuse a ﬁ xture built earlier is a key test automation decision.

When each test creates a Fresh Fixture, Erratic Tests (page 228) are less

likely and the testing effort is more likely to result in Tests as Documentation

(see page 23).

How It Works

We design and build the test ﬁ xture such that only a single run of a single test will

use it. We construct the ﬁ xture as part of running the test and tear down the ﬁ xture

when the test has ﬁ nished. We do not reuse any ﬁ xture left over by other tests or

other test runs. This way, we start and end every test with a “clean slate.”

Fixture

Setup

Exercise

Verify

Teardown

SUT

Fixture

Setup

Exercise

Verify

Teardown

SUT

Fixture

Setup

Exercise

Verify

Teardown

SUT

Fixture

Setup

Exercise

Verify

Teardown

SUT

Also known as:

Fresh Context,

Private Fixture

Fresh Fixture

Fresh

Fixture

311

When to Use It

We should use a Fresh Fixture whenever we want to avoid any interdependencies

between tests that can result in Erratic Tests such as Lonely Tests (see Erratic Test)

or Interacting Tests (see Erratic Test). If we cannot use a Fresh Fixture because it

slows the tests down too much, we should consider using an Immutable Shared

Fixture (see Shared Fixture on page 317) before resorting to a Shared Fixture.

Note that using a Database Partitioning Scheme (see Database Sandbox on page

650) to create a private Database Sandbox for the test that no other tests will

touch does not result in a Fresh Fixture because subsequent test runs could use

the same ﬁ xture.

Implementation Notes

A ﬁ xture is considered a Fresh Fixture if we intend to use it a single time. Whether

the Fresh Fixture is transient or persistent depends on the nature of the SUT and

how the tests are written (Figure 18.3). While the intent is the same, the implemen-

tation considerations are somewhat different when the Fresh Fixture is persistent.

Fixture setup is largely unaffected, so it is discussed as a feature common to all

such ﬁ xtures. Fixture teardown is speciﬁ c to the particular variation.

Figure 18.3 Test ﬁ xture strategies. A ﬁ xture can be either Fresh, Shared, or a

combination of the two (the immutable Shared Fixture) based on whether some,

or all, of it persists between tests.

Transient

Persistent

Immutable

Shared

Fixture

Shared

Fixture

Fresh

Fixture

Transient

Persistent

Immutable

Shared

Fixture

Shared

Fixture

Fresh

Fixture

Fresh

Fixture

Chapter 18 Test Strategy Patterns

312

Why Does a Fixture Persist?

The ﬁ xture we construct may hang around after the Test Method (page 348)

has ﬁ nished executing for one of two reasons. First, if the ﬁ xture primarily

consists of the state of some other objects or components on which the SUT

depends, its persistence is determined by whether those other objects are them-

selves persistent. A database is one such beast. That’s because as soon as some

code persists the ﬁ xture objects into a database, the objects “hang around”

long after our test is done. Their existence in the database opens the door

to collisions between multiple runs of our own test (Unrepeatable Test; see

Erratic Test). Other tests may also be able to access those objects, which can

result in other forms of Erratic Tests such as Interacting Tests and Test Run

Wars. If we must use a database or other form of object persistence, we should

take extra steps to keep the ﬁ xture private. In addition, we should tear down

the ﬁ xture after each Test Method.

The second reason that a ﬁ xture might persist lies within the control of our

tests—namely, which kind of variable we choose to hold the reference to the

ﬁ xture. Local variables naturally go out of scope when the Test Method ﬁ nishes

executing; therefore any ﬁ xture held in a local variable will be destroyed by

garbage collection. Instance variables go out of scope when the Testcase Object

is destroyed

and require explicit teardown only if the xUnit framework doesn’t

recreate the Testcase Objects during each test run. By contrast, class variables

usually result in persistent ﬁ xtures that can outlive a single test method or even

a test run and should therefore be avoided when using a Fresh Fixture.

In practice, our ﬁ xture will not normally be persistent in unit tests

unless

we have tightly coupled our application logic to the database. A ﬁ xture is more

likely to be persistent when we are writing customer tests or possibly compo-

nent tests.

Fresh Fixture Setup

Construction of the ﬁ xture is largely unaffected by whether it is persistent or tran-

sient. The primary consideration is the location of the code to set up the ﬁ xture. We

can use In-line Setup (page 408) if the ﬁ xture setup is relatively simple. For more

complex ﬁ xtures, we generally prefer using Delegated Setup (page 411) when our

Most members of the xUnit family create a separate Testcase Object (page 382) for

each Test Method. A few do not, however. This difference can trip up unwary test

automaters when they ﬁ rst start using these members of the family because instance

variables may unexpectedly act like class variables. For a detailed description of this

issue, see the sidebar “There’s Always an Exception” (page 384).

The sidebar “Unit Test Rulz” (page 307) explains what constitutes a unit test.

Fresh Fixture

Fresh

Fixture

313

Test Methods are organized using Testcase Class per Class (page 617) or Testcase

Class per Feature (page 624). We can use Implicit Setup (page 424) to build the

ﬁ xture if we have used the Testcase Class per Fixture (page 631) organization.

Variation: Transient Fresh Fixture

If we need to refer to the ﬁ xture from several places in the test, we should use

only local variables or instance variables to refer to the ﬁ xture. In most cases we

can depend on Garbage-Collected Teardown (page 500) to destroy the ﬁ xture

without any effort on our part.

Note that a Standard Fixture (page 305) can also be a

Fresh Fixture if the

ﬁ xture is built from scratch before each Test Method is run. This approach reuses

the design of the ﬁ xture rather than the instance. It is commonly encountered

when we use Implicit Setup but we are not using Testcase Class per Fixture to

organize our Test Methods.

Variation: Persistent Fresh Fixture

If we do end up using a Persistent Fresh Fixture, either we need to tear down the

ﬁ xture or we need to take special measures to avoid the need for its teardown.

We can tear down the ﬁ xture using In-line Teardown (page 509), Implicit Tear-

down (page 516), Delegated Teardown (see In-line Teardown), or Automated

Teardown (page 503) to leave the test environment in the same state as when

we entered it.

To avoid ﬁ xture teardown, we can use a Distinct Generated Value (see

Generated Value on page 723) for each ﬁ xture object that must be unique.

This strategy can become the basis of a Database Partitioning Scheme that

seeks to isolate the tests and test runners from one another. It would prevent

Resource Leakage (see Erratic Test) in case our teardown process fails. We can

also combine this approach with one of the teardown patterns to be doubly

sure that no Unrepeatable Tests or Interacting Tests exist.

Not surprisingly, this additional work has some drawbacks: It makes tests

more complicated to write and it often leads to Slow Tests (page 253). A natural

reaction is to take advantage of the persistence of the ﬁ xture by reusing it across

many tests, thereby avoiding the overhead of setting it up and tearing it down.

Unfortunately, this choice has many undesirable ramiﬁ cations because it violates

one of our major principles: Keep Tests Independent (see page 42). The result-

ing Shared Fixture invariably leads to Interacting Tests and Unrepeatable Tests,

if not immediately, then at some point down the road. We should not venture

down this road without fully understanding the consequences!

Fresh

Fixture

Chapter 18 Test Strategy Patterns

314

Motivating Example

Here’s an example of a Shared Fixture:

static Flight ﬂight;

public void setUp() {

if (ﬂight == null) { // Lazy SetUp

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

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

ﬂight = new Flight( ﬂightNumber,

departAirport,

destAirport);

}

public void testGetStatus_inital_S() {

// implicit setup

// exercise SUT and verify outcome

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

// teardown

}

public void testGetStatus_cancelled() {

// implicit setup partially overridden

ﬂight.cancel();

// exercise SUT and verify outcome

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

// teardown

}

Based on the code that actually sets up the ﬁ xture as shown here, it is a normal

Shared Fixture, but we could have just as easily used a Prebuilt Fixture (page 429)

for this motivating example. Either way, these tests could start interacting at any

time.

Refactoring Notes

Suppose we are using a Shared Fixture (same design, single copy) and decide to

refactor it to use a Fresh Fixture. We can start by refactoring the test to use a

fresh Standard Fixture (same design, many copies). Then we can decide whether

we want to further evolve the test so that it builds a Minimal Fixture (page 302)

by pruning the ﬁ xture setup logic to the bare minimum using a Minimize

Data (page 738) refactoring. This point would also be good time to group Test

Methods that need the same type of test ﬁ xture into a Testcase Class per Fixture

and use Implicit Setup; this use of a Standard Fixture would reduce the number

of Minimal Fixtures we need to design and build.

Fresh Fixture

Fresh

Fixture

315

Example: Fresh Fixture

Here’s the same test converted to a Fresh Fixture to avoid any possibility of

Interacting Tests:

public void testGetStatus_inital() {

// setup

Flight ﬂight = createAnonymousFlight();

// exercise SUT and verify outcome

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

// teardown

// garbage-collected

}

public void testGetStatus_cancelled2() {

// setup

Flight ﬂight = createAnonymousCancelledFlight();

// exercise SUT and verify outcome

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

// teardown

// garbage-collected

}

Note the use of Anonymous Creation Methods (see Creation Method on page 415)

to construct the appropriate state Flight object in each test.

Fresh

Fixture

316

Chapter 18 Test Strategy Patterns

317

Shared Fixture

How can we avoid Slow Tests?

Which ﬁ xture strategy should we use?

We reuse the same instance of the test ﬁ xture across many tests.

To execute an automated test, we require a text ﬁ xture that is well understood

and completely deterministic. Setting up a Fresh Fixture (page 311) can be time-

consuming, especially when we are dealing with complex system state stored in

a test database.

We can make our tests run faster by reusing the same ﬁ xture for several or

many tests.

How It Works

The basic concept is pretty simple: We create a Standard Fixture (page 305) ﬁ xture

that outlasts the lifetime of a single Testcase Object (page 382). This approach

allows multiple tests to reuse the same test ﬁ xture without destroying that ﬁ xture

and recreating it between tests. A Shared Fixture can be either a Prebuilt Fixture

that is reused by one or more tests in many test runs or a ﬁ xture that is created by

one test and reused by another test within the same test run. In either case, the key

consideration is that many tests do not create their own ﬁ xtures but rather reuse a

ﬁ xture “left over” from some other activity. The tests run faster because they have

less ﬁ xture setup to perform, which may result in the test automater having to do

less work to deﬁ ne the ﬁ xture for each test.

Setup

Exercise

Verify

Teardown

Fixture

Exercise

Verify

Teardown

SUT

Setup

Exercise

Verify

Teardown

Fixture

Exercise

Verify

Teardown

SUT

Also known as:

Shared Context,

Leftover Fixture,

Reused Fixture,

Stale Fixture

Shared Fixture

Shared

Fixture