Meszaros G. xUnit Test Patterns Refactoring Test Code

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

428

Flight ﬂight;

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);

}

public void testGetStatus_initial() {

// implicit setup

// exercise SUT and verify outcome

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

}

public void testGetStatus_cancelled() {

// implicit setup partially overridden

ﬂight.cancel();

// exercise SUT and verify outcome

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

}

This approach has several disadvantages, which arise because we are not

organizing our Test Methods around a Testcase Class per Fixture. (We are using

Testcase Class per Feature here.) All the Test Methods on the Testcase Class

must be able to make do with the same ﬁ xture (at least as a starting point), as

evidenced by the partially overridden ﬁ xture setup in the second test in the exam-

ple. The ﬁ xture is also not very obvious in these tests. Where does the ﬂ ight come

from? Is there anything special about it? We cannot even rename the instance

variable to communicate the nature of the ﬂ ight better because we are using it to

hold ﬂ ights with different characteristics in each test.

Implicit

Setup

Chapter 20 Fixture Setup Patterns

429

Prebuilt Fixture

How do we cause the Shared Fixture to be built before the ﬁ rst

test method that needs it?

We build the Shared Fixture separately from running the tests.

When we choose to use a Shared Fixture (page 317), whether it be for reasons

of convenience or out of necessity, we need to create the Shared Fixture before

we use it.

How It Works

We create the ﬁ xture sometime before running the test suite. We can create the

ﬁ xture a number of different ways that we’ll discuss later. The most important

point is that we don’t need to build the ﬁ xture each time the test suite is run

because the ﬁ xture outlives both the mechanism used to build it and any one

test run that uses it.

When to Use It

We can reduce the overhead of creating a Shared Fixture each time a test suite is

run by creating the ﬁ xture only occasionally. This pattern is especially appropri-

ate when the cost of constructing the Shared Fixture is extremely high or cannot

be automated easily.

Setup

Exercise

Verify

Teardown

Fixture

Exercise

Verify

Teardown

SUT

Test Runner

Setup

Exercise

Verify

Teardown

Fixture

Exercise

Verify

Teardown

SUT

Test Runner

Setup

Also known as:

Prebuilt

Context, Test

Bed

Prebuilt Fixture

Prebuilt

Fixture

430

Because of the Manual Intervention (page 250) required to (re)build the ﬁ xture

before the tests are run, we’ll probably end up using the same ﬁ xture several times,

which can lead to Erratic Tests (page 228) caused by shared ﬁ xture pollution. We

may be able to avoid these problems by treating the Prebuilt Fixture as an Immu-

table Shared Fixture (see Shared Fixture) and building a Fresh Fixture (page 311)

for anything we plan to modify.

The alternatives to a Prebuilt Fixture are a Shared Fixture that is built once

per test run and a Fresh Fixture. Shared Fixtures can be constructed using Suite

Fixture Setup (page 441), Lazy Setup (page 435), or Setup Decorator (page 447).

Fresh Fixtures can be constructed using In-line Setup (page 408), Implicit

Setup (page 424), or Delegated Setup (page 411).

Variation: Global Fixture

A Global Fixture is a special case of Prebuilt Fixture where we shared the ﬁ xture

between multiple test automaters. The key difference is that the ﬁ xture is globally

visible and not “private” to a particular user. This pattern is most commonly em-

ployed when we are using a single shared Database Sandbox (page 650) without

using some form of Database Partitioning Scheme (see Database Sandbox).

The tests themselves can be the same as those used for a basic Prebuilt Fix-

ture; likewise, the ﬁ xture setup is the same as that for a Prebuilt Fixture. What’s

different here are the kinds of problems we can encounter. Because the ﬁ xture

is now shared among multiple users, each of whom is running a separate Test

Runner (page 377) on a different CPU, we may experience all sorts of multipro-

cessing-related issues. The most common problem is a Test Run War (see Erratic

Test) where we see seemingly random results. We can avoid this possibility

by adopting some kind of Database Partitioning Scheme or by using Distinct

Generated Values (see Generated Value on page 723) for any ﬁ elds with unique

key constraints.

Implementation Notes

The tests themselves look identical to a basic Shared Fixture. What’s different is

how the ﬁ xture is set up. The test reader won’t be able to ﬁ nd any sign of it either

within the Testcase Class (page 373) or in a Setup Decorator or Suite Fixture

Setup method. Instead, the ﬁ xture setup is most probably performed manually

via some kind of database copy operation, by using a Data Loader (see Back

Door Manipulation on page 327) or by running a database population script. In

these examples of Back Door Setup (see Back Door Manipulation), we bypass

the SUT and interact with its database directly. (See the sidebar “Database as

Prebuilt

Fixture

Chapter 20 Fixture Setup Patterns

431

SUT API?” on page 336 for an example of when the back door really is a front

door.) Another option is to use a Fixture Setup Testcase (see Chained Tests on

page 454) run from a Test Runner either manually or on a regular schedule.

Another difference is how the Finder Methods (see Test Utility Method on

page 599) are implemented. We cannot just store the results of creating the

objects in a class variable or an in-memory Test Fixture Registry (see Test Helper

on page 643) because we aren’t setting the ﬁ xture up in code within the test

run. Two of the more commonly used options available to us are (1) to store

the unique identiﬁ ers generated during ﬁ xture construction in a persistent Test

Fixture Registry (such as a ﬁ le) as we build the ﬁ xture so that the Finder Meth-

ods can retrieve them later and (2) to hard-code the identiﬁ ers in the Finder

Methods. We could search for objects/records that meet the Finder Methods’

criteria at runtime, but that approach might result in Nondeterministic Tests

(see Erratic Test) because each test run could end up using a different object/re-

cord from the Prebuilt Fixture. This strategy may be a good idea if each test run

modiﬁ es the objects such that they no longer satisfy the criteria. Nevertheless, it

may make debugging a failing test rather difﬁ cult, especially if the failures occur

intermittently because some other attribute of the selected object is different.

Motivating Example

The following example shows the construction of a Shared Fixture using Lazy

Setup:

protected void setUp() throws Exception {

if (sharedFixtureInitialized) {

return;

}

facade = new FlightMgmtFacadeImpl();

setupStandardAirportsAndFlights();

sharedFixtureInitialized = true;

}

protected void tearDown() throws Exception {

// Cannot delete any objects because we don't know

// whether this is the last test

}

Note the call to setupStandardAirports in the setUp method. The tests use this ﬁ xture

by calling Finder Methods that return objects from the ﬁ xture that match certain

criteria:

Of course, there are other ways to set up the Shared Fixture, such as Setup Decorator

and Suite Fixture Setup.

Prebuilt

Fixture

Prebuilt Fixture

432

public void testGetFlightsByFromAirport_OneOutboundFlight()

throws Exception {

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 {

FlightDto[] outboundFlights =

ﬁndTwoOutboundFlightsFromOneAirport();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlights[0].getOriginAirportId());

// Verify Outcome

assertExactly2FlightsInDtoList( "Flights at origin",

outboundFlights,

ﬂightsAtOrigin);

}

Refactoring Notes

One way to convert a Testcase Class from a Standard Fixture (page 305) to a

Prebuilt Fixture is to do an Extract Class [Fowler] refactoring so that the ﬁ xture

is set up in one class and the Test Methods (page 348) are located in another

class. Of course, we need to provide a way for the Finder Methods to deter-

mine which objects or records exist in the structure because we won’t be able to

guarantee that any instance or class variables will bridge the time gap between

ﬁ xture construction and ﬁ xture usage.

Example: Prebuilt Fixture Test

Here is the resulting Testcase Class that contains the Test Methods. Note that it

looks almost identical to the basic Shared Fixture tests.

public void testGetFlightsByFromAirport_OneOutboundFlight()

throws Exception {

FlightDto outboundFlight = ﬁndOneOutboundFlight();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlight.getOriginAirportId());

// Verify Outcome

Prebuilt

Fixture

Chapter 20 Fixture Setup Patterns

433

assertOnly1FlightInDtoList( "Flights at origin",

outboundFlight,

ﬂightsAtOrigin);

}

public void testGetFlightsByFromAirport_TwoOutboundFlights()

throws Exception {

FlightDto[] outboundFlights =

ﬁndTwoOutboundFlightsFromOneAirport();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlights[0].getOriginAirportId());

// Verify Outcome

assertExactly2FlightsInDtoList( "Flights at origin",

outboundFlights,

ﬂightsAtOrigin);

}

What’s different is how the ﬁ xture is set up and how the Finder Methods are

implemented.

Example: Fixture Setup Testcase

We may ﬁ nd it to be convenient to set up our Prebuilt Fixture using xUnit. This is

simple to do if we already have the appropriate Creation Methods (page 415) or

constructors already deﬁ ned and we have a way to easily persist the objects into

the Database Sandbox. In the following example, we call the same method as in

the previous example from the setUp method, except that now the method lives

in the setUp method of a Fixture Setup Testcase that can be run whenever we want

to regenerate the Prebuilt Fixture:

public class FlightManagementFacadeSetupTestcase

extends AbstractFlightManagementFacadeTestCase {

public FlightManagementFacadeSetupTestcase(String name) {

super(name);

}

protected void setUp() throws Exception {

facade = new FlightMgmtFacadeImpl();

helper = new FlightManagementTestHelper();

setupStandardAirportsAndFlights();

saveFixtureInformation();

}

protected void tearDown() throws Exception {

// Leave the Prebuilt Fixture for later use

}

Prebuilt Fixture

Prebuilt

Fixture

434

Note that there are no Test Methods on this Testcase Class and the tearDown

method is empty. Here we want to do only the setup—nothing else.

Once we created the objects, we saved the information to the database using

the call to saveFixtureInformation; this method persists the objects and saves the

various keys in a ﬁ le so that we can reload them for use from the subsequent

real test runs. This approach avoids the need to hard-code knowledge of the

ﬁ xture into Test Methods or Test Utility Methods. In the interest of space, I’ll

spare you the details of how we ﬁ nd the “dirty” objects and save the key infor-

mation; there is more than one way to handle this task and any of these tactics

will sufﬁ ce.

Example: Prebuilt Fixture Setup Using a Data Population

Script

There are as many ways to build a Prebuilt Fixture in a Database Sandbox as

there are programming languages—everything from SQL scripts to Pearl and

Ruby programs. These scripts can contain the data or they can read the data

from a collection of ﬂ at ﬁ les. We can even copy the contents of a “golden” data-

base into our Database Sandbox. I’ll leave it as an exercise for you to ﬁ gure out

what’s most appropriate in your particular circumstance.

Prebuilt

Fixture

Chapter 20 Fixture Setup Patterns

435

Lazy Setup

How do we cause the Shared Fixture to be built before the

ﬁ rst test method that needs it?

We use Lazy Initialization of the ﬁ xture to create it in the ﬁ rst test that needs it.

Shared Fixtures (page 317) are often used to speed up test execution by reducing

the number of times a complex ﬁ xture needs to be created. Unfortunately, a test

that depends on other tests to set up the ﬁ xture cannot be run by itself; it is a

Lonely Test (see Erratic Test on page 228)

We can avoid this problem by having each test use Lazy Setup to set up the

ﬁ xture if it is not already set up.

How It Works

We use Lazy Initialization [SBPP] to construct the ﬁ xture in the ﬁ rst test that

needs it and then store a reference to the ﬁ xture in a class variable that every

test can access. All subsequently run tests will discover that the ﬁ xture is already

created and that they can reuse it, thereby avoiding the effort of constructing

the ﬁ xture anew.

setUp

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Test

Suite

Object

Exercise

Fixture

SUT

Implicit setUp

Is Fixture Set

Up Yet?

Create

setUp

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Test

Suite

Object

Exercise

Fixture

SUT

Implicit setUp

Is Fixture Set

Up Yet?

Create

Lazy Setup

436

When to Use It

We can use Lazy Setup whenever we need to create a Shared Fixture yet still

want to be able to run each test by itself. We can also use Lazy Setup instead

of other techniques such as Setup Decorator (page 447) and Suite Fixture Set-

up (page 441) if it is not crucial that the ﬁ xture be torn down. For example,

we could use Lazy Setup when we are using a ﬁ xture that can be torn down by

Garbage-Collected Teardown (page 500). We might also use Lazy Setup when

we are using Distinct Generated Values (see Generated Value on page 723) for

all database keys and aren’t worried about leaving extra records lying around

after each test; Delta Assertions (page 485) make this approach possible.

The major disadvantage of Lazy Setup is the fact that while it is easy to

discover that we are running the ﬁ rst test and need to construct the ﬁ xture,

it is difﬁ cult to determine that we are running the last test and the ﬁ xture

should be destroyed. Most members of the xUnit family of Test Automation

Frameworks (page 298) do not provide any way to determine this fact other

than by using a Setup Decorator for the entire test suite. A few members of the

xUnit family support Suite Fixture Setup (NUnit, VbUnit, and JUnit 4.0 and

newer, to name a few), which provides setUp/tearDown “bookends” for a Testcase

Class (page 373). Unfortunately, this ability won’t help us if we are writing our

tests in Ruby, Python, or PLSQL!

Some IDEs and Test Runners (page 377) automatically reload our classes every

time the test suite is run. This causes the original class variable to go out of scope,

and the ﬁ xture will be garbage-collected before the new version of the class is run.

In these cases there may be no negative consequence of using Lazy Setup.

A Prebuilt Fixture (page 429) is another alternative to setting up the Shared

Fixture for each test run. Its use can lead to Unrepeatable Tests (see Erratic

Test) if the ﬁ xture is corrupted by some of the tests.

Implementation Notes

Because Lazy Setup makes sense only with Shared Fixtures, Lazy Setup carries

all the same baggage that comes with Shared Fixtures.

Normally, Lazy Setup is used to build a Shared Fixture to be used by a single

Testcase Class. The reference to the ﬁ xture is held in a class variable. Things

get a bit trickier if we want to share the ﬁ xture across several Testcase Classes.

We could move both the Lazy Initialization logic and the class variable to a

Testcase Superclass (page 638) but only if our language supports inheritance of

class variables. The other alternative is to move the logic and variables to a Test

Helper (page 643).

Lazy Setup

Chapter 20 Fixture Setup Patterns

437

Of course, we could use an approach such as reference counting as a way

to know whether all Test Methods (page 348) have run. The challenge would

be to know how many Testcase Objects (page 382) are in the Test Suite

Object (page 387) so that we can compare this number with the number of times

the tearDown method has been called. I have never seen anyone do this so I won’t

call it a pattern! Adding logic to the Test Runner to invoke a tearDown method at

the Test Suite Object level would amount to implementing Suite Fixture Setup.

Motivating Example

In this example, we have been building a new ﬁ xture for each Testcase Object:

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

assertExactly2FlightsInDtoList( "Flights at origin",

outboundFlights,

ﬂightsAtOrigin);

}

Not surprisingly, these tests are slow because creating the airports and ﬂ ights

involves a database. We can try refactoring these tests to set up the ﬁ xture in the

setUp method (Implicit Setup; see page 424):

protected void setUp() throws Exception {

facade = new FlightMgmtFacadeImpl();

helper = new FlightManagementTestHelper();

setupStandardAirportsAndFlights();

oneOutboundFlight = ﬁndOneOutboundFlight();

}

Lazy Setup