Meszaros G. xUnit Test Patterns Refactoring Test Code

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

the post-test state of the SUT via a back door to compare it with expected

outcome. For customer tests, the back door is most commonly a test database,

but it could also be some other component on which the SUT depends, including

a Registry [PEAA] object or even the ﬁ le system. For unit tests, the back

door is some other class or object or an alternative interface of the SUT (or a

Test-Speciﬁ c Subclass; page 579) that exposes the state in a way “normal” clients

wouldn’t use. We can also replace a depended-on component (DOC) with a

suitably conﬁ gured Test Double (page 522) instead of using the real thing if

that makes the job easier.

When to Use It

We might choose to use Back Door Manipulation for several reasons which we’ll

examine in more detail shortly. A prerequisite for using this technique is that some

sort of back door to the state of the system must exist. The main drawback of

Back Door Manipulation is that our tests—or the Test Utility Methods (page 599)

they call—become much more closely coupled to the design decisions we make

about how to represent the state of the SUT. If we need to change those decisions,

we may encounter Fragile Tests (page 239). We need to decide whether this price

is acceptable on a case-by-case basis. We can greatly reduce the impact of the close

coupling by encapsulating all Back Door Manipulation in Test Utility Methods.

Using Back Door Manipulation can also lead to Obscure Tests (page 186) by

hiding the relationship of the test outcome to the test ﬁ xture. We can avoid this

problem by including the test data being passed to the Back Door Manipulation

mechanism within the Testcase Class (page 373), or at least mitigate it by using

Finder Methods (see Test Utility Method) to refer to the objects in the ﬁ xture

via intent-revealing names.

A common application of Back Door Manipulation involves testing basic

CRUD (Create, Read, Update, Delete) operations on the SUT’s state. In such a

case, we want to verify that the information persisted and can be recovered in the

same form. It is difﬁ cult to write round-trip tests for “Read” without also testing

“Create”; likewise, it is difﬁ cult to test “Update” or “Delete” without testing both

“Create” and “Read.” We can certainly test these operations by using round-trip

tests, but this kind of testing won’t detect certain types of systemic problems, such

as putting information into the wrong database column. One solution is to con-

duct layer-crossing tests that use

Back Door Manipulation to set up or verify the

contents of the database directly. For a “Read” test, the test sets up the contents

of the database using Back Door Setup and then asks the SUT to read the data.

For a “Write” test, the test asks the system to write certain objects and then uses

Back Door Veriﬁ cation on the contents of the database.

Back Door

Manipulation

Chapter 18 Test Strategy Patterns

328

Variation: Back Door Setup

One reason for doing Back Door Manipulation is to make tests run faster. If a

system does a lot of processing before putting data into its data store, the time it

takes for a test to set up the ﬁ xture via the SUT’s API could be quite signiﬁ cant.

One way to make the tests run faster is to determine what those data stores

should look like and then create a means to set them up via the back door

rather than through the API. Unfortunately, this technique introduces its own

problem: Because Back Door Setup bypasses enforcement of the object creation

business rules, we may ﬁ nd ourselves creating ﬁ xtures that are not realistic and

possibly even invalid. This problem may creep in over time as the business rules

are modiﬁ ed in response to changing business needs. At the same time, this ap-

proach may allow us to create test scenarios that the SUT will not let us set up

through its API.

When we share a database between our SUT and another application, we

need to verify that we are using the database correctly and that we can handle

all possible data conﬁ gurations the other applications might create. Back Door

Setup is a good way to establish these conﬁ gurations—and it may be the only

way if the SUT either doesn’t write those tables or writes only speciﬁ c (and

valid) data conﬁ gurations. Back Door Setup lets us create those “impossible”

conﬁ gurations easily so we can verify how the SUT behaves in these situations.

Variation: Back Door Veriﬁ cation

Back Door Veriﬁ cation involves sneaking in to do State Veriﬁ cation of the SUT’s

post-exercise state via a back door; it is mostly applicable to customer tests (or

functional tests, as they are sometimes called). The back door is typically an

alternative way to examine the objects in the database, usually through a stan-

dard API such as SQL or via data exports that can then be examined with a ﬁ le

comparison utility program.

As mentioned earlier, Back Door Manipulation can make tests run faster. If

the only way to get at the SUT’s state is to invoke an expensive operation (such

as a complex report) or an operation that further modiﬁ es the SUT’s state, we

may be better off using Back Door Manipulation.

Another reason for doing Back Door Manipulation is that other systems

expect the SUT to store its state in a speciﬁ c way, which they can then access

directly. This is a form of indirect output. In this situation, standard round-trip

tests cannot prove that the SUT’s behavior is correct because they cannot

detect a systematic problem if the “Write” and “Read” operations make the

same mistake, such as putting information into the wrong database column.

The solution is a layer-crossing test that looks at the contents of the database

Back Door Manipulation

Back Door

Manipulation

329

directly to verify that the information is stored correctly. For a “Write” test,

the test asks the system to write certain objects and then inspects the contents

of the database via the back door.

Variation: Back Door Teardown

We can also use Back Door Manipulation to tear down a Fresh Fixture (page 311)

that is stored in a test database. This ability is especially beneﬁ cial if we can use

bulk database commands to wipe clean whole tables, as in Table Truncation

Teardown (page 661) or Transaction Rollback Teardown (page 668).

Implementation Notes

How we implement Back Door Manipulation depends on where the ﬁ xture lives

and how easily we can access the state of the SUT. It also depends on why we

are doing Back Door Manipulation. This section lists the most common imple-

mentations, but feel free to use your imagination and come up with other ways

to use this pattern.

Variation: Database Population Script

When the SUT stores its state in a database that it accesses as it runs, the easiest

way to do Back Door Manipulation is to load data directly into that database

before invoking the SUT. This approach is most commonly required when we

are writing customer tests, but it may also be required for unit tests if the classes

we are testing interact directly with the database. We must ﬁ rst determine the

pre-conditions of the test and, from that information, identify the data that the

test requires for its ﬁ xture. We then deﬁ ne a database script that inserts the cor-

responding records directly into the database bypassing the SUT logic. We use

this Database Population Script whenever we want to set up the test ﬁ xture—a

decision that depends on which test ﬁ xture strategy we have chosen. (See Chap-

ter 6, Test Automation Strategy, for more on that topic.)

When deciding to use a Database Population Script, we will need to maintain

both the Database Population Script and the ﬁ les it takes as input whenever we

modify either the structure of the SUT’s data stores or the semantics of the data

in them. This requirement can increase the maintenance cost of the tests.

Variation: Data Loader

A Data Loader is a special program that loads data into the SUT’s data store.

It differs from a Database Population Script in that the Data Loader is written

in a programming language rather than a database language. This gives us a bit

Back Door

Manipulation

Chapter 18 Test Strategy Patterns

330

more ﬂ exibility and allows us to use the Data Loader even when the system state

is stored somewhere other than a relational database.

If the data store is external to the SUT, such as in a relational database, the

Data Loader can be “just another application” that writes to that data store.

It would use the database in much the same way as the SUT but would get its

inputs from a ﬁ le rather than from wherever the SUT normally gets its inputs

(e.g., other “upstream” programs). When we are using an object relational

mapping (ORM) tool to access the database from our SUT, a simple way to

build the Data Loader is to use the same domain objects and mappings in our

Data Loader. We just create the desired objects in memory and commit the

ORM’s unit of work to save them into the database.

If the SUT stores data in internal data structures (e.g., in memory), the Data

Loader may need to be an interface provided by the SUT itself. The following

characteristics differentiate it from the normal functionality provided by the SUT:

• It is used only by the tests.

• It reads the data from a ﬁ le rather than wherever the SUT normally gets

the data.

• It bypasses a lot of the “edit checks” (input validation) normally done

by the SUT.

The input ﬁ les may be simple ﬂ at ﬁ les containing comma- or tab-delimited text,

or they could be structured using XML. DbUnit is an extension of JUnit that

implements Data Loader for ﬁ xture setup.

Variation: Database Extraction Script

When the SUT stores its state in a database that it accesses as it runs, we can

take advantage of this structure to do Back Door Veriﬁ cation. We simply use a

database script to extract data from the test database and verify that it contains

the right data either by comparing it to previously prepared “extract” ﬁ les or by

ensuring that speciﬁ c queries return the right number of records.

Variation: Data Retriever

A Data Retriever is the analog of a Data Loader that retrieves the state from the

SUT when doing Back Door Veriﬁ cation. Like a trusty dog, it “fetches” the data

so that we can compare it with our expected results within our tests. DbUnit is an

extension of JUnit that implements Data Retriever to support result veriﬁ cation.

Back Door Manipulation

Back Door

Manipulation

331

Variation: Test Double as Back Door

So far, all of the implementation techniques described here have involved inter-

acting with a DOC of the SUT to set up or tear down the ﬁ xture or to verify the

expected outcome. Probably the most common form of Back Door Manipula-

tion involves replacing the DOC with a Test Double. One option is to use a

Fake Object (page 551) that we have preloaded with some data as though the

SUT had already been interacting with it; this strategy allows us to avoid using

the SUT to set up the SUT’s state. The other option is to use some kind of Con-

ﬁ gurable Test Double (page 558), such as a Mock Object (page 544) or a Test

Stub (page 529). Either way, we can completely avoid Obscure Tests by making

the state of the Test Double visible within the Test Method (page 348).

When we want to perform Behavior Veriﬁ cation (page 468) of the calls made

by the SUT to one or more DOCs, we can use a layer-crossing test that replaces

the DOC with a Test Spy (page 538) or a Mock Object. When we want to

verify that the SUT behaves a speciﬁ c way when it receives indirect inputs from

a DOC (or when in some speciﬁ c external state), we can replace the DOC with

a Test Stub.

Motivating Example

The following round-trip test veriﬁ es the basic functionality of removing a ﬂ ight

by interacting with the SUT only via the front door. But it does not verify the

indirect outputs of the SUT—namely, that the SUT is expected to call a logger to

log each time a ﬂ ight is removed along with the day/time when the request was

made and the user ID of the requester. In many systems, this would be an ex-

ample of “layer-crossing behavior”: The logger is part of a generic infrastructure

layer, while the SUT is an application-speciﬁ c behavior.

public void testRemoveFlight() throws Exception {

// setup

FlightDto expectedFlightDto = createARegisteredFlight();

FlightManagementFacade facade = new FlightManagementFacadeImpl();

// exercise

facade.removeFlight(expectedFlightDto.getFlightNumber());

// verify

assertFalse("ﬂight should not exist after being removed",

facade.ﬂightExists( expectedFlightDto.

getFlightNumber()));

}

Back Door

Manipulation

Chapter 18 Test Strategy Patterns

332

Refactoring Notes

We can convert this test to use Back Door Veriﬁ cation by adding result veriﬁ cation

code to access and verify the logger’s state. We can do so either by reading that state

from the logger’s database or by replacing the logger with a Test Spy that saves the

state for easy access by the tests.

Example: Back Door Result Veriﬁ cation Using a Test Spy

Here’s the same test converted to use a Test Spy to access the post-test state of

the logger:

public void testRemoveFlightLogging_recordingTestStub()

throws Exception {

// ﬁxture setup

FlightDto expectedFlightDto = createAnUnregFlight();

FlightManagementFacade facade =

new FlightManagementFacadeImpl();

// Test Double setup

AuditLogSpy logSpy = new AuditLogSpy();

facade.setAuditLog(logSpy);

// exercise

facade.removeFlight(expectedFlightDto.getFlightNumber());

// verify

assertEquals("number of calls", 1,

logSpy.getNumberOfCalls());

assertEquals("action code",

Helper.REMOVE_FLIGHT_ACTION_CODE,

logSpy.getActionCode());

assertEquals("date", helper.getTodaysDateWithoutTime(),

logSpy.getDate());

assertEquals("user", Helper.TEST_USER_NAME,

logSpy.getUser());

assertEquals("detail",

expectedFlightDto.getFlightNumber(),

logSpy.getDetail());

}

This approach would be the better way to verify the logging if the logger’s data-

base contained so many entries that it wasn’t practical to verify the new entries

using Delta Assertions (page 485).

Example: Back Door Fixture Setup

The next example shows how we can set up a ﬁ xture using the database as a

back door to the SUT. The test inserts a record into the EmailSubscription table

and then asks the SUT to ﬁ nd it. It then makes assertions on various ﬁ elds of the

object returned by the SUT to verify that the record was read correctly.

Back Door Manipulation

Back Door

Manipulation

333

static ﬁnal String TABLE_NAME = "EmailSubscription";

static ﬁnal BigDecimal RECORD_ID = new BigDecimal("111");

static ﬁnal String LOGIN_ID = "Bob";

static ﬁnal String EMAIL_ID = "bob@foo.com";

public void setUp() throws Exception {

String xmlString =

"<?xml version='1.0' encoding='UTF-8'?>" +

"<dataset>" +

" <" + TABLE_NAME +

" EmailSubscriptionId='" + RECORD_ID + "'" +

" UserLoginId='" + LOGIN_ID + "'" +

" EmailAddress='" + EMAIL_ID + "'" +

" RecordVersionNum='62' " +

" CreateByUserId='MappingTest' " +

" CreateDateTime='2004-03-01 00:00:00.0' " +

" LastModByUserId='MappingTest' " +

" LastModDateTime='2004-03-01 00:00:00.0'/>" +

"</dataset>";

insertRowsIntoDatabase(xmlString);

}

public void testRead_Login() throws Exception {

// exercise

EmailSubscription subs =

EmailSubscription.ﬁndInstanceWithId(RECORD_ID);

// verify

assertNotNull("Email Subscription", subs);

assertEquals("User Name", LOGIN_ID, subs.getUserName());

}

public void testRead_Email() throws Exception {

// exercise

EmailSubscription subs =

EmailSubscription.ﬁndInstanceWithId(RECORD_ID);

// verify

assertNotNull("Email Subscription", subs);

assertEquals("Email Address",

EMAIL_ID,

subs.getEmailAddress());

}

The XML document used to populate the database is built within the Testcase

Class so as to avoid the Mystery Guest (see Obscure Test) that would have been

created if we had used an external ﬁ le for loading the database [the discussion of

the In-line Resource (page 736) refactoring explains this approach]. To make the

test clearer, we call intent-revealing methods that hide the details of how we use

DbUnit to load the database and clean it out at the end of the test using Table

Truncation Teardown. Here are the bodies of the Test Utility Methods used in

this example:

Back Door

Manipulation

334

Chapter 18 Test Strategy Patterns

private void insertRowsIntoDatabase(String xmlString)

throws Exception {

IDataSet dataSet = new FlatXmlDataSet(new StringReader(xmlString));

DatabaseOperation.CLEAN_INSERT.

execute( getDbConnection(), dataSet);

}

public void tearDown() throws Exception{

emptyTable(TABLE_NAME);

}

public void emptyTable(String tableName) throws Exception {

IDataSet dataSet = new DefaultDataSet(new DefaultTable(tableName));

DatabaseOperation.DELETE_ALL.

execute(getDbConnection(), dataSet);

}

Of course, the implementations of these methods are speciﬁ c to DbUnit; we

must change them if we use some other member of the xUnit family.

Some other observations on these tests: To avoid an Eager Test (see Assertion

Roulette on page 224), the assertion on each ﬁ eld appears in a separate

test. This structure could result in Slow Tests (page 253) because these tests

interact with a database. We could use Lazy Setup (page 435) or Suite Fixture

Setup (page 441) to avoid setting up the ﬁ xture more than once as long as the

resulting Shared Fixture (page 317) was not modiﬁ ed by any of the tests. (I

chose not to further complicate this example by taking this tack.)