Meszaros G. xUnit Test Patterns Refactoring Test Code

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

448

run the test, the Test Runner calls the run method on our Setup Decorator rather

than the run method on the actual Test Suite Object. The Setup Decorator

performs the ﬁ xture setup before calling the run method on the Test Suite Object

and tears down the ﬁ xture after it returns.

When to Use It

We can use a Setup Decorator when it is critical that a Shared Fixture be set up

before every test run and that the ﬁ xture is torn down after the run is complete.

This behavior may be critical because tests are using Hard-Coded Values (see

Literal Value on page 714) that would cause the tests to fail if they are run

again without cleaning up after each run (Unrepeatable Tests; see Erratic Test on

page 228). Alternatively, this behavior may be necessary to avoid the incremental

consumption of some limited resource, such as our database slowly ﬁ lling up

with data from repeated test runs.

We might also use a Setup Decorator when the tests need to change some global

parameter before exercising the SUT and then need to change this parameter back

when they are ﬁ nished. Replacing the database with a Fake Database (see Fake

Object on page 551) in an effort to avoid Slow Tests (page 253) is one common

reason for taking this approach; setting global switches to a particular conﬁ gura-

tion is another. Setup Decorators are installed at runtime, so nothing stops us

from using several different decorators on the same test suite at different times (or

even the same time).

As an alternative to a Setup Decorator, we can use Suite Fixture Setup

(page 441) if we only want to share the ﬁ xture across the tests in a single Testcase

Class (page 373) and our member of the xUnit family supports this behavior. If

it is not essential that the ﬁ xture be torn down after every test run, we could use

Lazy Setup instead.

Implementation Notes

A Setup Decorator consists of an object that sets up the ﬁ xture, delegates test

execution to the test suite to be run, and then executes the code to tear down the

ﬁ xture. To better line up with the normal xUnit calling conventions, we typically

put the code that constructs the test ﬁ xture into a method called setUp and the

code that tears down the ﬁ xture into a method called tearDown. Then our Setup

Decorator’s run logic consists of three lines of code:

Setup

Decorator

Chapter 20 Fixture Setup Patterns

449

void run() {

setup();

decoratedSuite.run();

teardown();

}

There are several ways to build the Setup Decorator.

Variation: Abstract Setup Decorator

Many members of the xUnit family of Test Automation Frameworks (page 298)

provide a reusable superclass that implements a Setup Decorator. This class

usually implements the setUp/run/tearDown sequence as a Template Method [GOF].

All we have to do is to subclass this class and implement the setUp and tearDown

methods as we would in a normal Testcase Class. When instantiating our Setup

Decorator class, we pass the Test Suite Object we are decorating as the construc-

tor argument.

Variation: Hard-Coded Setup Decorator

If we need to build our Setup Decorator from scratch, the “simplest thing that

could possibly work” is to hard-code the name of the decorated class in the

suite method of the Setup Decorator. This allows the Setup Decorator class

to act as the Test Suite Factory (see Test Enumeration on page 399) for the

decorated suite.

Variation: Parameterized Setup Decorator

If we want to reuse the Setup Decorator for different test suites, we can param-

eterize its constructor method with the Test Suite Object to be run. This means

that the setup and teardown logic can be coded within the Setup Decorator,

thereby eliminating the need for a separate Test Helper (page 643) class just to

reuse the setup logic across tests.

Variation: Decorated Lazy Setup

One of the main drawbacks of using a Setup Decorator is that tests cannot

be run by themselves because they depend on the Setup Decorator to set up

the ﬁ xture. We can work around this requirement by augmenting the Setup

Decorator with Lazy Setup in the setUp method so that an undecorated Testcase

Object (page 382) can construct its own ﬁ xture. The Testcase Object can also

remember that it built its own ﬁ xture and destroy it in the tearDown method. This

functionality could be implemented on a generic Testcase Superclass (page 638)

so that it has to be built and tested just once.

Setup Decorator

Setup

Decorator

450

The only other alternative is to use a Pushdown Decorator. That would negate

any test speedup the Shared Fixture bought us, however, so this approach can

be used only in those cases when we use the Setup Decorator for reasons other

than setting up a Shared Fixture.

Variation: Pushdown Decorator

One of the main drawbacks of using a Setup Decorator is that tests cannot be

run by themselves because they depend on the Setup Decorator to set up the

ﬁ xture. One way we can circumvent this obstacle is to provide a means to push

the decorator down to the level of the individual tests rather than the whole test

suite. This step requires a few modiﬁ cations to the TestSuite class to allow the

Setup Decorator to be passed down to where the individual Testcase Objects

are constructed during the Test Discovery (page 393) process. As each object is

created from the Test Method (page 348), it is wrapped in the Setup Decorator

before it is added to the Test Suite Object’s collection of tests.

Of course, this negates one of the major sources of the speed advantage created

by using a Setup Decorator by forcing a new test ﬁ xture to be built for each

test. See the sidebar “Faster Tests Without Shared Fixtures” on page 319 for

other ways to address the test execution speed issue.

Motivating Example

In this example, we have a set of tests that use Lazy Setup to build the Shared

Fixture and Finder Methods (see Test Utility Method on page 599) to ﬁ nd the

objects in the ﬁ xture. We have discovered that the leftover ﬁ xture is causing

Unrepeatable Tests, so we want to clean up properly after the last test has ﬁ n-

ished running.

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

}

Setup

Decorator

Chapter 20 Fixture Setup Patterns

451

Because there is no easy way to accomplish this goal with Lazy Setup, we

must change our ﬁ xture setup strategy. One option is to use a Setup Decorator

instead.

Refactoring Notes

When creating a Setup Decorator, we can reuse the exact same ﬁ xture setup

logic; we just need to call it at a different time. Thus this refactoring consists

mostly of moving the call to the ﬁ xture setup logic from the setUp method on the

Testcase Class to the setUp method of a Setup Decorator class. Assuming we have

an Abstract Setup Decorator available to subclass, we can create our new sub-

class and provide concrete implementations of the setUp and tearDown methods.

If our instance of xUnit does not support Setup Decorator directly, we can

create our own Setup Decorator superclass by building a single-purpose Setup

Decorator and then introducing a constructor parameter and instance variable

to hold the test suite to be run. Finally, we do an Extract Superclass [Fowler]

refactoring to create our reusable superclass.

Example: Hard-Coded Setup Decorator

In this example, we have moved all of the setup logic to the setUp method of

a Setup Decorator that inherits its basic functionality from an Abstract Setup

Decorator. We have also written some ﬁ xture teardown logic in the tearDown

method so that we clean up the ﬁ xture after the entire test suite has been run.

public class FlightManagementTestSetup extends TestSetup {

private FlightManagementTestHelper helper;

public FlightManagementTestSetup() {

// Construct the Test Suite Object to be decorated and

// pass it to our Abstract Setup Decorator superclass

super( SafeFlightManagementFacadeTest.suite() );

helper = new FlightManagementTestHelper();

}

public void setUp() throws Exception {

helper.setupStandardAirportsAndFlights();

}

public void tearDown() throws Exception {

helper.removeStandardAirportsAndFlights();

}

Setup Decorator

Setup

Decorator

452

public static Test suite() {

// Return an instance of this decorator class

return new FlightManagementTestSetup();

}

Because this is a Hard-Coded Setup Decorator, the call to the Test Suite Factory

that builds the actual Test Suite Object is hard-coded inside the constructor. The

suite method just calls the constructor.

Example: Parameterized Setup Decorator

To make our Setup Decorator reusable with several different test suites, we need

to do an Introduce Parameter [JBrains] refactoring on the name of the Test Suite

Factory inside the constructor:

public class ParameterizedFlightManagementTestSetup extends TestSetup {

private FlightManagementTestHelper helper =

new FlightManagementTestHelper();

public ParameterizedFlightManagementTestSetup(

Test testSuiteToDecorate) {

super(testSuiteToDecorate);

}

public void setUp() throws Exception {

helper.setupStandardAirportsAndFlights();

}

public void tearDown() throws Exception {

helper.removeStandardAirportsAndFlights();

}

To make it easy for the Test Runner to create our test suite, we also need to cre-

ate a Test Suite Factory that calls the Setup Decorator’s constructor with the Test

Suite Object to be decorated:

public class DecoratedFlightManagementFacadeTestFactory {

public static Test suite() {

// Return a new Test Suite Object suitably decorated

return new ParameterizedFlightManagementTestSetup(

SafeFlightManagementFacadeTest.suite());

}

Setup

Decorator

Chapter 20 Fixture Setup Patterns

453

We will need one of these Test Suite Factories for each test suite we want to be

able to run by itself. Even so, this is a small price to pay for reusing the actual

Setup Decorator.

Example: Abstract Decorator Class

Here’s what the Abstract Decorator Class looks like:

public class TestSetup extends TestCase {

Test decoratedSuite;

AbstractSetupDecorator(Test testSuiteToDecorate) {

decoratedSuite = testSuiteToDecorate;

}

public void setUp() throws Exception {

// subclass responsibility

}

public void tearDown() throws Exception {

// subclass responsibility

}

void run() {

setup();

decoratedSuite.run();

teardown();

}

Setup Decorator

Setup

Decorator

454

Chained Tests

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

ﬁ rst test method that needs it?

We let the other tests in a test suite set up the test ﬁ xture.

Shared Fixtures (page 317) are commonly used to reduce the amount of per-

test overhead required to set up the ﬁ xture. Sharing a ﬁ xture involves extra test

programming effort because we need to create the ﬁ xture and have a way of

discovering the ﬁ xture in each test. Regardless of how the ﬁ xture is accessed, it

must be initialized (constructed) before it is used.

Chained Tests offer a way to reuse the test ﬁ xture left over from one test and

the Shared Fixture of a subsequent test.

How It Works

Chained Tests take advantage of the objects created by the tests that run before our

current test in the test suite. This approach is very similar to how a human tester

tests a large number of test conditions in a single test—by building up a complex

test ﬁ xture through a series of actions, with the outcome of each action ﬁ rst being

veriﬁ ed. We can achieve a similar result with automated tests by building a set of

Self-Checking Tests (see page 26) that do not perform any ﬁ xture setup but instead

Fixture

Exercise

Verify

SUT

Exercise

Verify

Exercise

Verify

Test Runner

Fixture

Exercise

Verify

SUT

Exercise

Verify

Exercise

Verify

Test Runner

Fixture

Chained

Tests

Chapter 20 Fixture Setup Patterns

455

rely on the “leftovers” of the test(s) that run before them. Unlike with the Reuse

Test for Fixture Setup pattern (see Creation Method on page 415), we don’t actu-

ally call another Test Method (page 348) from within out test; we just assume that

it has been run and has left behind something we can use as a test ﬁ xture.

When to Use It

Chained Tests is a ﬁ xture strategy that people either love or hate. Those who

hate it do so because this approach is simply the test smell Interacting Tests (see

Erratic Test on page 228) recast as a pattern. Those who love it typically do so

because it solves a nasty problem introduced by using Shared Fixtures to deal

with Slow Tests (page 253). Either way, it is a valid strategy for refactoring exist-

ing tests that are overly long and contain many steps that build on one another.

Such tests will stop executing when the ﬁ rst assertion fails. We can refactor

such tests into a set of Chained Tests fairly quickly because this strategy doesn’t

require determining exactly which test ﬁ xture we need to build for each test.

This may be the ﬁ rst step in evolving the tests into a set of Independent Tests

(see page 42).

Chained Tests help prevent Fragile Tests (page 239) because they are a crude

form of SUT API Encapsulation (see Test Utility Method on page 599). Our

test doesn’t need to interact with the SUT to set up the ﬁ xture because we

let another test that was already using the same API set up the ﬁ xture for us.

Fragile Fixtures (see Fragile Test) may be a problem, however; if one of the

preceding tests is modiﬁ ed to create a different ﬁ xture, the depending test will

probably fail. This is also true if some of the earlier tests fail or have errors;

they may leave the Shared Fixture in a different state from what the current

test expects.

One of the key problems with Chained Tests is the nondeterminism of the

order in which xUnit executes tests in a test suite. Most members of the family

make no guarantees about this order (TestNG is an exception). Thus tests could

start to fail when a new version of xUnit is installed or even when one of the

Test Methods is renamed [if the xUnit implementation happens to sort the Test-

case Objects (page 382) by method name].

Another problem is that Chained Tests are Lonely Tests (see Erratic Test)

because the current test depends on the tests that precede it to set up the test

ﬁ xture. If we run the test by itself, it will likely fail because the test ﬁ xture

it assumes is not set up for it. As a consequence, we cannot run just the one test

when we are debugging failures it exposes.

Depending on other tests to set up the test ﬁ xture invariably results in tests

that are more difﬁ cult to understand because the test ﬁ xture is invisible to the

Chained Tests

Chained

Tests

456

test reader—a classic case of a Mystery Guest (see Obscure Test on page 186).

This problem can be at least partially mitigated through the use of appropri-

ately named Finder Methods (see Test Utility Method) to access the objects in

the Shared Fixture. It is less of an issue if all the Test Methods are on the same

Testcase Class (page 373) and are listed in the same order as they are executed.

Variation: Fixture Setup Testcase

If we need to set up a Shared Fixture and we cannot use any of the other tech-

niques to set it up [e.g., Lazy Setup (page 435), Suite Fixture Setup (page 441),

or Setup Decorator (page 447)], we can arrange to have a Fixture Setup Testcase

run as the ﬁ rst test in the test suite. This is simple to do if we are using Test Enu-

meration (page 399); we just include the appropriate addTest method call in our

Test Suite Factory (see Test Enumeration). This variation is a degenerate form

of the Chained Tests pattern in that we are chaining a test suite behind a single

Fixture Setup Testcase.

Implementation Notes

There are two key challenges in implementing Chained Tests:

• Getting tests in the test suite to run in the desired order

• Accessing the ﬁ xture leftover by the previous test(s)

While a few members of the xUnit family provide an explicit mechanism for

deﬁ ning the order of tests, most members make no such guarantees about this

order. We can probably ﬁ gure out what order the xUnit member uses by per-

forming a few experiments. Most commonly, we will discover that it is either the

order in which the Test Methods appear in the ﬁ le or alphabetical order by Test

Method name (in which case, the easiest solution is to include a test sequence

number in the test name). In the worst-case scenario, we could always revert

to Test Method Enumeration (see Test Enumeration) to ensure that Testcase

Objects are added to the test suite in the correct order.

To refer to the objects created by the previous tests, we need to use one of the

ﬁ xture object access patterns. If the preceding tests are Test Methods on the same

Testcase Class, it is sufﬁ cient for each test to store any object references that subse-

quent tests will use to access the ﬁ xture in a ﬁ xture holding class variable. (Fixture

holding instance variables typically won’t work here because each test runs on a

separate Testcase Object and, therefore, the tests don’t share instance variables.

See the sidebar “There’s Always an Exception” on page 384 for a description of

when instance variations do not behave this way.)

Chained

Tests

Chapter 20 Fixture Setup Patterns

457

If our test depends on a Test Method on a different Testcase Class being run

as a part of a Suite of Suites (see Test Suite Object on page 387), neither of these

solutions will work. Our best bet will be to use a Test Fixture Registry (see Test

Helper on page 643) as the means to store references to the objects used by the

tests. A test database is a good example.

Obviously, we don’t want the test we are depending on to clean up after

itself—that would leave nothing for us to reuse as our test ﬁ xture. That re-

quirement makes Chained Tests incompatible with the Fresh Fixture (page 311)

approach.

Motivating Example

Here’s an example of an incremental Tabular Test (see Parameterized Test on

page 607) provided by Clint Shank on his blog:

public class TabularTest extends TestCase {

private Order order = new Order();

private static ﬁnal double tolerance = 0.001;

public void testGetTotal() {

assertEquals("initial", 0.00, order.getTotal(), tolerance);

testAddItemAndGetTotal("ﬁrst", 1, 3.00, 3.00);

testAddItemAndGetTotal("second",3, 5.00, 18.00);

// etc.

}

private void testAddItemAndGetTotal( String msg,

int lineItemQuantity,

double lineItemPrice,

double expectedTotal) {

// setup

LineItem item = new LineItem( lineItemQuantity, lineItemPrice);

// exercise SUT

order.addItem(item);

// verify total

assertEquals(msg,expectedTotal,order.getTotal(),tolerance);

}

This test begins by building an empty order, veriﬁ es the total is zero, and then

proceeds to add several items verifying the total after each item (Figure 20.3).

The main issue with this test is that if one of the subtests fails, all subsequent

subtests don’t get run. For example, suppose a rounding error makes the total

after the second item incorrect: Wouldn’t we like to see whether the fourth, ﬁ fth,

and six items are still correct?

Chained Tests

Chained

Tests