Meszaros G. xUnit Test Patterns Refactoring Test Code

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

This page intentionally left blank

499

Chapter 22

Fixture Teardown Patterns

Patterns in This Chapter

Teardown Strategy

Garbage-Collected Teardown . . . . . . . . . . . . . . . . . . . . . . . . . . . 500

Automated Teardown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Code Organization

In-line Teardown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

Implicit Teardown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

Fixture

Teardown

Patterns

500

Chapter 22 Fixture Teardown Patterns

Garbage-Collected Teardown

How do we tear down the Test Fixture?

We let the garbage collection mechanism provided by the programming

language clean up after our test.

A large part of making tests repeatable and robust is ensuring that the test ﬁ x-

ture is torn down after each test and a new one created for the next test run.

This strategy is known as a Fresh Fixture (page 311). In languages that provide

garbage collection, much of the teardown can happen automatically if we refer

to resources via local and instance variables.

How It Works

Many of the objects created during the course of our test (including both ﬁ xture

setup and exercising the SUT) are transient objects that are kept alive only as

long as there is a reference to them somewhere in the program that created them.

The garbage collection mechanisms of modern languages use various algorithms

to detect “garbage.” What is most important, though, is how they determine

that something is not garbage: Any object that is reachable from any other live

object or from global (i.e., static) variables will not be garbage collected.

When running our tests, the Test Automation Framework (page 298) creates

a Testcase Object (page 382) for each Test Method (page 348) in our Testcase

Fixture

SUT

Setup

Testcase Class

tearDown

test_method_1

test_method_2

test_method_n

Setup

Garbage

Collection

Teardown

Fixture

SUT

Setup

Testcase Class

tearDown

test_method_1

test_method_2

test_method_n

Setup

Garbage

Collection

Teardown

Garbage-

Collected

Teardown

501

Class (page 373) and adds those objects to a Test Suite Object (page 387). When-

ever a new test run is started, the framework typically throws away the existing

test suite and builds a new one (to be sure everything is fresh). When the old test

suite is discarded, any objects referenced only by instance variables in those tests

become candidates for garbage collection.

When to Use It

We should use Garbage-Collected Teardown whenever we possibly can because

it will save us a lot of effort!

If our programming takes place in an environment that doesn’t support garbage

collection, or if we have resources that aren’t garbage collected automatically (e.g.,

ﬁ les, sockets, records in a database), we’ll need to destroy or free those resources

explicitly. If we are using a Shared Fixture (page 317), we won’t be able to use

Garbage-Collected Teardown unless we do something fancy to hold the reference

to the ﬁ xture in such a way that it will go out of scope when our test suite has

ﬁ nished running.

We can use In-line Teardown (page 509), Implicit Teardown (page 516), or

Automated Teardown (page 503) to ensure that they are released properly.

Implementation Notes

Some members of the xUnit family and some IDEs go so far as to replace the

classes each time the test suite is run. We may see this behavior show up as an

option called “Reload Classes” or it may be forced upon us. We must be care-

ful if we decide to take advantage of this feature to perform Garbage-Collected

Teardown with ﬁ xture holding class variables, as our tests may stop running

if we change IDEs or try running our tests from the command line (e.g., from

“Cruise Control” or a build script.)

Motivating Example

The following test creates some in-memory objects during ﬁ xture setup and

explicitly destroys them using In-line Teardown. (We could have used Implicit

Teardown in this example but that just makes it harder for readers to see what

is going on.)

public void testCancel_proposed_UIT() {

// ﬁxture setup

Flight proposedFlight = createAnonymousProposedFlight();

// exercise SUT

proposedFlight.cancel();

Garbage-Collected Teardown

Garbage-

Collected

Teardown

502

Chapter 22 Fixture Teardown Patterns

// verify outcome

try{

assertEquals( FlightState.CANCELLED,

proposedFlight.getStatus());

} ﬁnally {

// teardown

proposedFlight.delete();

proposedFlight = null;

}

Because these objects are not persistent, the code to delete the proposedFlight is

unnecessary and just makes the test more complicated and harder to understand.

Refactoring Notes

To convert to Garbage-Collected Teardown, we need only remove the unneces-

sary cleanup code. If we had been using a class variable to hold the reference to

the object, we would have had to convert it to either an instance variable or a

local variable, both of which would have moved us from a Shared Fixture to a

Fresh Fixture.

Example: Garbage-Collected Teardown

In this reworked test, we let Garbage-Collected Teardown do the job for us.

public void testCancel_proposed_GCT() {

// ﬁxture setup

Flight proposedFlight = createAnonymousProposedFlight();

// exercise SUT

proposedFlight.cancel();

// verify outcome

assertEquals( FlightState.CANCELLED,

proposedFlight.getStatus());

// teardown

// Garbage collected when proposedFlight goes out of scope

}

Note how much simpler the test has become!

Garbage-

Collected

Teardown

503

Automated Teardown

How do we tear down the Test Fixture?

We keep track of all resources that are created in a test and automatically

destroy/free them during teardown.

A large part of making tests repeatable and robust is ensuring that the test

ﬁ xture is torn down after each test and a new one created for the next test

run. This strategy is known as a Fresh Fixture (page 311). Leftover objects

and database records, as well as open ﬁ les and connections, can at best cause

performance degradations and at worst cause tests to fail or systems to crash.

While some of these resources may be cleaned up automatically by garbage

collection, others may be left hanging if they are not torn down explicitly.

Writing teardown code that can be relied upon to clean up properly in all possible

circumstances is challenging and time-consuming. It involves understanding what

could be left over for each possible outcome of the test and writing code to deal with

that scenario. This Complex Teardown (see Obscure Test on page 186) introduces

a fair bit of Conditional Test Logic (page 200) and—worst of all—Untestable Test

Code (see Hard-to-Test Code on page 209).

A better solution is to let the test infrastructure track the objects created and

clean them up auto-magically when the test is complete.

Fixture

SUT

Testcase Class

tearDown

test_method_1

test_method_2

test_method_n

Creation

Test Object

Registry

Destroy All

Teardown

Re g ister

Test Object

Fixture

SUT

Testcase Class

tearDown

test_method_1

test_method_2

test_method_n

Creation

Test Object

Registry

Destroy All

Teardown

Re g ister

Test Object

Automated Teardown

Automated

Teardown

Also known as:

Test Object

Registry

504

Chapter 22 Fixture Teardown Patterns

How It Works

The core of the solution is a mechanism to register each persistent item (i.e.,

object, record, connection, and so on) we create in the test. We maintain a list

(or lists) of registered objects that need some action to be taken to destroy them.

This can be as simple as tossing each object into a collection. At the end of the

test, we traverse the collection and destroy each object. We will want to catch

any errors that we encounter so that one object’s cleanup error will not cause the

rest of the cleanup to be aborted.

When to Use It

We can use Automated Teardown whenever we have persistent resources that

need to be cleaned up to keep the test environment functioning. (This happens

more often in customer tests than in unit tests.) This pattern addresses both

Unrepeatable Tests (see Erratic Test on page 228) and Interacting Tests (see

Erratic Test) by keeping the objects created in one test from lingering into the

execution of a subsequent test.

Automated Teardown isn’t very difﬁ cult to build, and it will save us a large

amount of grief and effort. Once we have built it for one project, we should be

able to reuse the teardown logic on subsequent projects for very little effort.

Implementation Notes

Automated Teardown comes in two ﬂ avors. The basic ﬂ avor tears down only

objects that were created as part of ﬁ xture setup. The more advanced version also

destroys any objects that were created by the SUT while it was being exercised.

Variation: Automated Fixture Teardown

The simplest solution is to register the objects we create in our Creation Methods

(page 415). Although this pattern will not tear down the objects created by the

SUT, by dealing with our ﬁ xture it reduces the effort and likelihood of errors

signiﬁ cantly.

There are two key challenges with this variation:

• Finding a generic way to clean up the registered objects

• Ensuring that our Automated Teardown code is run for each registered

object

Given that the latter challenge is the easier problem, let us deal with it ﬁ rst.

When we are tearing down a Persistent Fresh Fixture (see Fresh Fixture), the

Automated

Teardown

505

simplest solution is to put the call to the Automated Teardown mechanism into

the tearDown method on our Testcase Class (page 373). This method is called

regardless of whether the test passes or fails as long as the setUp method succeeds.

When we are tearing down a Shared Fixture (page 317), we want the tearDown

method to run only after all the Test Methods (page 348) have been run. In this

case, we can use either Suite Fixture Setup (page 441), if our member of the

xUnit family supports it, or a Setup Decorator (page 447).

Now let’s go back to the harder problem: the generic mechanism for cleaning

up the resources. We have at least two options here. First, we can ensure that all

persistent (non-garbage-collected) objects implement a generic cleanup mechanism

that we can call from within the Automated Teardown mechanism. Alternatively,

we can wrap each object in another object that knows how to clean up the object

in question. The latter strategy is an example of the Command [GOF] pattern.

If we build our Automated Teardown mechanism in a completely generic

way, we can include it in the Testcase Superclass (page 638) on which we can

base all our Testcase Classes. Otherwise, we may need to put it onto a Test

Helper (page 643) that is visible from all Testcase Classes that need it. A Test

Helper that both creates ﬁ xture objects and tears them down automatically is

sometimes called an Object Mother (see Test Helper).

Being a nontrivial (and very critical) piece of code, the Automated Teardown

mechanism deserves its own unit tests. Because it is now outside the Test Method,

we can write Self-Checking Tests (see page 26) for it! If we want to be really

careful (some might say paranoid), we can use Delta Assertions (page 485) to

verify that any objects that persist after the teardown operation really existed

before the test was performed.

Variation: Automated Exercise Teardown

We can make the tests even more “self-cleaning” by also cleaning up the objects

created by the SUT. This effort involves designing the SUT using an observable

Object Factory (see Dependency Lookup on page 686) so that we can automati-

cally register any objects created by the SUT while it is being exercised. During

the teardown phase we can delete these objects, too.

Motivating Example

In this example, we create several objects using Creation Methods and need to

tear them down when the test in complete. To do so, we introduce a try/ﬁ nally

block to ensure that our In-line Teardown (page 509) code executes even when

the assertions fail.

Automated Teardown

Automated

Teardown

506

Chapter 22 Fixture Teardown Patterns

public void testGetFlightsByOrigin_NoInboundFlight_SMRTD()

throws Exception {

// Fixture Setup

BigDecimal outboundAirport = createTestAirport("1OF");

BigDecimal inboundAirport = null;

FlightDto expFlightDto = null;

try {

inboundAirport = createTestAirport("1IF");

expFlightDto = createTestFlight(outboundAirport, inboundAirport);

// Exercise System

List ﬂightsAtDestination1 =

facade.getFlightsByOriginAirport(inboundAirport);

// Verify Outcome

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

} ﬁnally {

try {

facade.removeFlight(expFlightDto.getFlightNumber());

} ﬁnally {

try {

facade.removeAirport(inboundAirport);

} ﬁnally {

facade.removeAirport(outboundAirport);

}

Note that we must use nested try/ﬁ nally constructs within the ﬁ nally block to

ensure that any errors in the teardown don’t keep us from ﬁ nishing the job.

Refactoring Notes

Introducing Automated Teardown involves two steps. First, we add the

Automated Teardown mechanism to our Testcase Class. Second, we remove

any In-line Teardown code from our tests.

Automated Teardown can be implemented on a speciﬁ c Testcase Class or it can

be inherited (or mixed in) via a generic class. Either way, we need to make sure we

them when the test is ﬁ nished. This is most easily done inside Creation Methods

that already exist. Alternatively, we can use an Extract Method [Fowler] refactoring

to move the direct constructor calls into newly created Creation Methods and add

the registration.

The generic Automated Teardown mechanism should be invoked from the

tearDown method. Although this can be done on our own Testcase Class, it is

almost always better to put this method on a Testcase Superclass that all our

Testcase Classes inherit from. If we don’t already have a Testcase Superclass,

Automated

Teardown

507

we can easily create one by doing an Extract Class [Fowler] refactoring and

then doing a Pull Up Method [Fowler] refactoring on any methods (and ﬁ elds)

associated with the Automated Teardown mechanism.

Example: Automated Teardown

There is not much to see in this refactored test because all of the teardown code

has been removed.

public void testGetFlightsByOriginAirport_OneOutboundFlight()

throws Exception {

// Fixture Setup

BigDecimal outboundAirport = createTestAirport("1OF");

BigDecimal inboundAirport = createTestAirport("1IF");

FlightDto expectedFlightDto =

createTestFlight( outboundAirport, inboundAirport);

// Exercise System

List ﬂightsAtOrigin =

facade.getFlightsByOriginAirport(outboundAirport);

// Verify Outcome

assertOnly1FlightInDtoList( "Flights at origin",

expectedFlightDto,

ﬂightsAtOrigin);

}

Here is where all the work gets done! The Creation Method has been modiﬁ ed

to register the object it just created.

private List allAirportIds;

private List allFlights;

protected void setUp() throws Exception {

allAirportIds = new ArrayList();

allFlights = new ArrayList();

}

private BigDecimal createTestAirport(String airportName)

throws FlightBookingException {

BigDecimal newAirportId = facade.createAirport(

airportName, " Airport" + airportName,

"City" + airportName);

allAirportIds.add(newAirportId);

return newAirportId;

}

Next comes the actual Automated Teardown logic. In this example, it lives on

our Testcase Class and is called from the tearDown method. To keep this example

very simple, this logic has been written speciﬁ cally to handle airports and ﬂ ights.

More typically, it would live in the Testcase Superclass, where it could be used

Automated Teardown

Automated

Teardown