Meszaros G. xUnit Test Patterns Refactoring Test Code

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

In-line Setup

How do we construct the Fresh Fixture?

Each Test Method creates its own Fresh Fixture by calling the

appropriate constructor methods to build exactly the test ﬁ xture

it requires.

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

and completely deterministic. We can use the Fresh Fixture (page 311) approach

to build a Minimal Fixture (page 302) for the use of this one test. Setting up the

test ﬁ xture on an in-line basis in each test is the most obvious way to build it.

How It Works

Each Test Method (page 348) sets up its own test ﬁ xture by directly calling what-

ever SUT code is required to construct exactly the test ﬁ xture it requires. We put

the code that creates the ﬁ xture, the ﬁ rst phase of the Four-Phase Test (page 358),

at the top of each Test Method.

Fixture

SUT

Testcase Class

setUp

test_1

test_2

test_n

Setup

Fixture

SUT

Testcase Class

setUp

test_1

test_2

test_n

Setup

In-line Setup

Chapter 20 Fixture Setup Patterns

408

When to Use It

We can use In-line Setup when the ﬁ xture setup logic is very simple and straightforward.

As soon as the ﬁ xture setup gets at all complex, we should consider using Delegated

Setup (page 411) or Implicit Setup (page 424) for part or all of the ﬁ xture setup.

We can also use In-line Setup when we are writing a ﬁ rst draft of tests and haven’t

yet ﬁ gured out which part of the ﬁ xture setup will be repeated from test to test.

This is an example of applying the “Red–Green–Refactor” process pattern to the

tests themselves. Nevertheless, we need to be careful when we refactor the tests to

ensure that we don’t break the tests in ways that are undetectable.

A third occasion to use In-line Setup is when refactoring obtuse ﬁ xture setup

code. A ﬁ rst step may be to use In-line Method [Fowler] refactorings on all

Creation Methods (page 415) and the setUp method. Then we can try using a

series of Extract Method [Fowler] refactorings to deﬁ ne a new set of Creation

Methods that are more intent-revealing and reusable.

Implementation Notes

In practice, most ﬁ xture setup logic will include a mix of styles, such as In-line

Setup building on top of Implicit Setup or Delegated Setup interspersed with

In-line Setup.

Example: In-line Setup

Here’s an example of simple in-line setup. Everything each Test Method needs

for exercising the SUT is included in-line.

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

}

public void testStatus_cancelled() {

// in-line setup

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

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

In-line Setup

409

410

Flight ﬂight = new Flight( ﬂightNumber,

departureAirport,

destinationAirport);

ﬂight.cancel(); // still part of setup

// exercise SUT and verify outcome

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

// tearDown:

// garbage-collected

}

Refactoring Notes

In-line Setup is normally the starting point for refactoring, not the end goal.

Sometimes, however, we ﬁ nd ourselves with tests that are too hard to under-

stand because of all the stuff happening behind the scenes, which is a form of

Mystery Guest (see Obscure Test on page 186). At other times, we may ﬁ nd

ourselves modifying the previously setup ﬁ xture in many of the tests.

Both of these situations are indications it may be time to refactor our test

class into multiple classes based on the ﬁ xture they build. First, we use an In-

line Method refactoring on the code to produce an In-line Setup. Next, we

reorganize the tests using an Extract Class [Fowler] refactoring. Finally, we use

a series of Extract Method refactorings to deﬁ ne a more understandable set of

ﬁ xture setup methods.

In-line Setup

Chapter 20 Fixture Setup Patterns

Delegated Setup

How do we construct the Fresh Fixture?

Each Test Method creates its own Fresh Fixture by calling Creation Methods

from within the Test Methods.

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

and completely deterministic. We are using a Fresh Fixture (page 311) approach

to build a Minimal Fixture (page 302) for the use of this one test and we’d like

to avoid Test Code Duplication (page 213).

Delegated Setup lets us reuse the code to set up the ﬁ xture without compromis-

ing our goal of Tests as Documentation (see page 23).

How It Works

Each Test Method (page 348) sets up its own test ﬁ xture by calling one or more

Creation Methods (page 415) to construct exactly the test ﬁ xture it requires.

To ensure Tests as Documentation, we build a Minimal Fixture using Creation

Methods that build fully formed objects that are ready for use by the test. We

strive to ensure that the method calls will convey the “big picture” to the test

reader by passing in only those values that affect the behavior of the SUT.

Fixture

SUT

Utility

Method

Testcase Class

setUp

test_1

test_2

test_n

Utility

Method

Setup

Fixture

SUT

Utility

Method

Testcase Class

setUp

test_1

test_2

test_n

Utility

Method

Setup

Delegated

Setup

Delegated Setup

411

412

When to Use It

We can use a Delegated Setup when we want to avoid the Test Code Duplication

caused by having to set up similar ﬁ xtures for several tests and we want to keep

the nature of the ﬁ xture visible within the Test Methods. A reasonable goal is to

encapsulate the essential but irrelevant steps of setting up the ﬁ xture and leave

only the steps and values essential to understanding the test within the Test Meth-

od. This scheme helps us achieve Tests as Documentation by ensuring that excess

In-line Setup (page 408) code does not obscure the intent of the test. It also avoids

the Mystery Guest problem (see Obscure Test on page 186) by leaving the Intent-

Revealing Name [SBPP] of the Creation Method call within the Test Method.

Furthermore, Delegated Setup allows us to use whatever organization scheme

we want for our Test Methods. In particular, we are not forced to put Test Methods

that require the same test ﬁ xture into the same Testcase Class (page 373) just to

reuse the setUp method as we would have to when using Implicit Setup (page 424).

Furthermore, Delegated Setup helps prevent Fragile Tests (page 239) by moving

much of the nonessential interaction with the SUT out of the very numerous Test

Methods and into a much smaller number of Creation Method bodies, where it is

easier to maintain.

Implementation Notes

With modern refactoring tools, we can often create the ﬁ rst cut of a Creation

Method by performing a simple Extract Method [Fowler] refactoring. As we are

writing a set of tests using “clone and twiddle,” we must watch for any Test Code

Duplication in the ﬁ xture setup logic within our tests. For each object that needs to

be veriﬁ ed in the veriﬁ cation logic, we extract a Creation Method that takes only

those attributes as parameters that affect the outcome of the test.

Initially, we can leave the Creation Method on our Testcase Class. If we need

to share them with another class, however, we can move the Creation Methods

to an Abstract Testcase class (see Testcase Superclass on page 638) or a Test

Helper (page 643) class.

Motivating Example

Suppose we are testing the state model of the Flight class. In each test, we need

to have a ﬂ ight in the right state. Because a ﬂ ight needs to connect at least two

airports, we need to create airports before we can create a ﬂ ight. Of course, air-

ports are typically associated with cities or states/provinces. To keep the example

manageable, let’s assume that our airports require only a city name and an air-

port code.

Delegated

Setup

Chapter 20 Fixture Setup Patterns

413

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

}

public void testStatus_cancelled() {

// in-line setup

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

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

Flight ﬂight = new Flight( ﬂightNumber,

departureAirport,

destinationAirport);

ﬂight.cancel(); // still part of setup

// Exercise SUT and verify outcome

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

// teardown

// garbage-collected

}

These tests contain a fair amount of Test Code Duplication.

Refactoring Notes

We can refactor the ﬁ xture setup logic by using an Extract Method refactoring

to remove any frequently repeated code sequences into utility methods with

Intent-Revealing Names. We leave the calls to the methods in the test, however,

so that the reader can see what is being done. The method calls that remain

within the test will convey the “big picture” to the test reader. The utility meth-

od bodies contain the irrelevant mechanics of carrying out the intent. If we need

to share the Delegated Setups with another Testcase Class, we can use either a

Pull Up Method [Fowler] refactoring to move them to a Testcase Superclass or

a Move Method [Fowler] refactoring to move them to a Test Helper class.

Example: Delegated Setup

In this version of the test, we use a method that hides the fact that we need two

airports instead of creating the two airports needed by the ﬂ ight within each Test

Method. We could produce this version of the tests either through refactoring or

by writing the test in this intent-revealing style right off the bat.

Delegated Setup

Delegated

Setup

414

public void testGetStatus_initial() {

// 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

}

The simplicity of these tests was made possible by the following Creation Methods,

which hide the “necessary but irrelevant” steps from the test reader:

private int uniqueFlightNumber = 2000;

public Flight createAnonymousFlight(){

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

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

Flight ﬂight =

new Flight( new BigDecimal(uniqueFlightNumber++),

departureAirport,

destinationAirport);

return ﬂight;

}

public Flight createAnonymousCancelledFlight(){

Flight ﬂight = createAnonymousFlight();

ﬂight.cancel();

return ﬂight;

}

Delegated

Setup

Chapter 20 Fixture Setup Patterns

415

Creation Method

How do we construct the Fresh Fixture?

We set up the test ﬁ xture by calling methods that hide the mechanics of

building ready-to-use objects behind Intent-Revealing Names.

Fixture setup usually involves the creation of a number of objects. In many

cases, the details of those objects (i.e., the attribute values) are unimportant but

must be speciﬁ ed to satisfy each object’s constructor method. Including all of

this unnecessary complexity within the ﬁ xture setup part of the test can lead to

Obscure Tests (page 186) and certainly doesn’t help us achieve Tests as Docu-

mentation (see page 23)!

How can a properly initialized object be created without having to clutter

the test with In-line Setup (page 408)? The answer, of course, is to encapsulate

this complexity. Delegated Setup (page 411) moves the mechanics of the ﬁ xture

setup into other methods but leaves overall control and coordination within

the test itself. But what to delegate to? A Creation Method is one way we can

encapsulate the mechanics of object creation so that irrelevant details do not

distract the reader.

Fixture

Setup

Exercise

Verify

Teardown

SUT

Creation

Method

Fixture

Setup

Exercise

Verify

Teardown

SUT

Creation

Method

Creation Method

Creation

Method

416

How It Works

As we write tests, we don’t bother asking whether a desired utility function

exists; we just use it! (It helps to pretend that we have a loyal helper sitting

next to us who will quickly ﬁ ll in the bodies of any functions we call that do

not exist as yet.) We write our tests in terms of these magic functions with

Intent-Revealing Names [SBPP], passing as parameters only those things that

will be veriﬁ ed in the assertions or that should affect the outcome of the test.

Once we’ve written the test in this very intent-revealing style, we must implement

all of the magic functions that we’ve been calling. The functions that create objects

are our Creation Methods; they encapsulate the complexity of object creation. The

simple ones call the appropriate constructor, passing it suitable default values for

anything needed but not supplied as a parameter. If any of the constructor argu-

ments are other objects, the Creation Method will ﬁ rst create those depended-on

objects before calling the constructor.

The Creation Method may be placed in all the same places where we put

Test Utility Methods (page 599). As usual, the decision is based on the expected

scope of reuse and the Creation Method’s dependencies on the API of the SUT.

A related pattern is Object Mother (see Test Helper on page 643), which is a

combination of Creation Method, Test Helper, and optionally Automated Tear-

down (page 503).

When to Use It

We should use a Creation Method whenever constructing a Fresh Fixture

(page 311) requires signiﬁ cant complexity and we value Tests as Documentation.

Another key indicator for using Creation Method is that we are building the

system in a highly incremental way and we expect the API of the system (and

especially the object constructors) to change frequently. Encapsulating knowl-

edge of how to create a ﬁ xture object is a special case of SUT API Encapsulation

(see Test Utility Method), and it helps us avoid both Fragile Tests (page 239) and

Obscure Tests.

The main drawback of a Creation Method is that it creates another API for

test automaters to learn. This isn’t much of a problem for the initial test devel-

opers because they are typically involved in building this API but it can create

“one more thing” for new additions to the team to learn. Even so, this API

should be pretty easy to understand because it is just a set of Factory Methods

[GOF] organized in some way.

If we are using a Prebuilt Fixture (page 429), we should use Finder Methods

(see Test Utility Method) to locate the prebuilt objects. At the same time, we

Creation

Method

Chapter 20 Fixture Setup Patterns

417

may still use Creation Methods to lay mutable objects that we plan to modify

on top of an Immutable Shared Fixture (see Shared Fixture on page 317).

Several variations of Creation Method are worth exploring.

Variation: Parameterized Creation Method

While it is possible (and often very desirable) for Creation Methods to take no

parameters whatsoever, many tests will require some customization of the cre-

ated object. A Parameterized Creation Method allows the test to pass in some

attributes to be used in the creation of the object. In such a case, we should pass

only those attributes that are expected to affect (or those we want to demon-

strate do not affect) the test’s outcome; otherwise, we could be headed down the

slippery slope to Obscure Tests.

Variation: Anonymous Creation Method

An Anonymous Creation Method automatically creates a Distinct Generated

Value (see Generated Value on page 723) as the unique identiﬁ er for the object it

is creating even though the arguments it receives may not be unique. This behav-

ior is invaluable for avoiding Unrepeatable Tests (see Erratic Test on page 228)

because it ensures that every object we create is unique, even across multiple test

runs. If the test cares about some attributes of the object to be created, it can

pass them as parameters of the Creation Method; this behavior turns the Anony-

mous Creation Method into a Parameterized Anonymous Creation Method.

Variation: Parameterized Anonymous Creation Method

A Parameterized Anonymous Creation Method is a combination of several other

variations of Creation Method in that we pass in some attributes to be used in

the creation of the object but let the Creation Method create the unique identi-

ﬁ er for it. A Creation Method could also take zero parameters if the test doesn’t

care about any of the attributes.

Variation: Named State Reaching Method

Some SUTs are essentially stateless, meaning we can call any method at any

time. By contrast, when the SUT is state-rich and the validity or behavior of

methods is affected by the state of the SUT, it is important to test each method

from each possible starting state. We could chain a bunch of such tests together

in a single Test Method (page 348), but that approach would create an Eager

Test (see Assertion Roulette on page 224). It is better to use a series of Single-

Condition Tests (see page 45) for this purpose. Unfortunately, that leaves us

Creation

Method

Creation Method