Meszaros G. xUnit Test Patterns Refactoring Test Code

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

458

Figure 20.3 Tabular Test results. The lower pane shows the details of the ﬁ rst

failure inside the single Tabular Test method listed in the upper pane. Because of

the failure, the rest of the test method is not executed.

Refactoring Notes

We can convert this Tabular Test to a set of Chained Tests simply by breaking up

the single Test Method into one Test Method per subtest. One way to do so is to

use a series of Extract Method [Fowler] refactorings to create the Test Methods.

This will force us to use an Introduce Field [JetBrains] refactoring for any local

variables before the ﬁ rst Extract Method refactoring operation. Once we have de-

ﬁ ned all of the new Test Methods, we simply delete the original Test Method and

let the Test Automation Framework (page 298) call our new methods directly.

We need to ensure the tests run in the same order. Because JUnit seems to

sort the Testcase Objects by method name, we can force them into the right

order by including a sequence number in the Test Method name.

Finally, we need to convert our Fresh Fixture into a Shared Fixture. We do

so by changing our order ﬁ eld (instance variable) into a class variable (a static

variable in Java) so that all of the Testcase Objects use the same Order.

If we don’t have a refactoring tool handy, no worries. Just end the Test Method after

each subtest and type in the signature of the next Test Method before the next subtest. We

then move any Shared Fixture variables out of the ﬁ rst Test Method.

Chained

Tests

Chapter 20 Fixture Setup Patterns

459

Example: Chained Tests

Here’s the simple example turned into three separate tests:

private static Order order = new Order();

private static ﬁnal double tolerance = 0.001;

public void test_01_initialTotalShouldBeZero() {

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

}

public void test_02_totalAfter1stItemShouldBeOnlyItemAmount(){

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

}

public void test_03_totalAfter2ndItemShouldBeSumOfAmounts() {

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

}

private void testAddItemAndGetTotal( String msg,

int lineItemQuantity,

double lineItemPrice,

double expectedTotal) {

// create a line item

LineItem item =

new LineItem(lineItemQuantity, lineItemPrice);

// add line item to order

order.addItem(item);

// verify total

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

}

The Test Runner (page 377) gives us a better overview of what is wrong and

what is working (Figure 20.4).

Unfortunately, we will not be able to run any of the tests by themselves while

we debug this problem (except for the very ﬁ rst test) because of the interdepen-

dencies between the tests; they are Lonely Tests.

Chained

Tests

Chained Tests

460

Figure 20.4 Chained Tests result. The upper pane shows the three test methods

with two tests passing. The lower pane shows the details of the one failing Test

Method.

Chained

Tests

Chapter 20 Fixture Setup Patterns

Chapter 21

Result Veriﬁ cation Patterns

Patterns in This Chapter

Veriﬁ cation Strategy

State Veriﬁ cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

Behavior Veriﬁ cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Assertion Method Styles

Custom Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Delta Assertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

Guard Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

Unﬁ nished Test Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Result

Veriﬁ cation

Patterns

461

462

Chapter 21 Result Verification Patterns

State Veriﬁ cation

How do we make tests self-checking when there is state to be veriﬁ ed?

We inspect the state of the system under test after it has been exercised and

compare it to the expected state.

A Self-Checking Test (see page 26) must verify that the expected outcome has

occurred without manual intervention by whoever is running the test. But what

do we mean by “expected outcome”? The SUT may or may not be “stateful”; if

it is stateful, it may or may not have a different state after it has been exercised.

As test automaters, it is our job to determine whether our expected outcome is a

change of ﬁ nal state or whether we need to be more speciﬁ c about what occurs

while the SUT is being exercised.

State Veriﬁ cation involves inspecting the state of the SUT after it has been

exercised.

How It Works

We exercise the SUT by invoking the methods of interest. Then, as a separate

step, we interact with the SUT to retrieve its post-exercise state and compare it

with the expected end state by calling Assertion Methods (page 362).

Fixture

SUT

DOC

Exercise

Setup

Exercise

Verify

Teardown

Get State

Behavior

(Indirect

Outputs)

Fixture

SUT

DOC

Exercise

Setup

Exercise

Verify

Teardown

Get State

Behavior

(Indirect

Outputs)

Also known as:

State-Based

Testing

State

Veriﬁ cation

463

Normally, we can access the state of the SUT simply by calling methods or

functions that return its state. This is especially true when we are doing test-driven

development because the tests will have ensured that the state is easily accessible.

When we are retroﬁ tting tests, however, we may ﬁ nd it more challenging to access

the relevant state information. In these cases, we may need to use a Test-Speciﬁ c

Subclass (page 579) or some other technique to expose the state without introduc-

ing Test Logic in Production (page 217).

A related question is “Where is the state of the SUT stored?” Sometimes, the

state is stored within the actual SUT; in other cases, the state may be stored in

another component such as a database. In the latter case, State Veriﬁ cation may

involve accessing the state within the other component (essentially a layer-crossing

test). By contrast, Behavior Veriﬁ cation (page 468) would involve verifying the

interactions between the SUT and the other component.

When to Use It

We should use State Veriﬁ cation when we care about only the end state of the

SUT—not how the SUT got there. Taking such a limited view helps us maintain

encapsulation of the implementation of the SUT.

State Veriﬁ cation comes naturally when we are building the software inside

out. That is, we build the innermost objects ﬁ rst and then build the next layer

of objects on top of them. Of course, we may need to use Test Stubs (page 529)

to control the indirect inputs of the SUT to avoid Production Bugs (page 268)

caused by untested code paths. Even then, we are choosing not to verify the

indirect outputs of the SUT.

When we do care about the side effects of exercising the SUT that are not

visible in its end state (its indirect outputs), we can use Behavior Veriﬁ cation to

observe the behavior directly. We must be careful, however, not to create Fragile

Tests (page 239) by overspecifying the software.

Implementation Notes

There are two basic styles of implementing State Veriﬁ cation.

Variation: Procedural State Veriﬁ cation

When doing Procedural State Veriﬁ cation, we simply write a series of calls to

Assertion Methods that pick apart the state information into pieces and com-

pare those bits of information to individual expected values. Most people who

are new to automating tests take such a “path of least resistance.” The major

disadvantage of this approach is that it can result in Obscure Tests (page 186)

State Verification

State

Veriﬁ cation

464

Chapter 21 Result Verification Patterns

owing to the number of assertions it may take to specify the expected outcome.

When the same sequence of assertions must be carried out in many tests or many

times within a single Test Method (page 348), we also have Test Code Duplica-

tion (page 213).

Variation: Expected State Speciﬁ cation

When doing Expected State Speciﬁ cation, we construct a speciﬁ cation for the

post-exercise state of the SUT in the form of one or more objects populated with

the expected attributes. We then compare the actual state directly with these

objects using a single call to an Equality Assertion (see Assertion Method). This

tends to result in more concise and readable tests. We can use an Expected State

Speciﬁ cation whenever we need to verify several attributes and it is possible to

construct an object that looks like the object we expect the SUT to return. The

more attributes we have that need to be compared and the more tests that need

to compare them, the more compelling the argument for using an Expected State

Speciﬁ cation. In the most extreme cases, when we have a lot of data to verify, we

can construct an “expected table” and verify that the SUT contains it. Fit’s “row

ﬁ xtures” offer a good way to do this in customer tests; tools such as DbUnit are

a good way to use Back Door Manipulation (page 327) for this purpose.

When constructing the Expected State Speciﬁ cation, we may prefer to use

a Parameterized Creation Method (see Creation Method on page 415) so that

the reader is not distracted by all the necessary but unimportant attributes of

the Expected State Speciﬁ cation. The Expected State Speciﬁ cation is most often

an instance of the same class that we expect to get back from the SUT. We may

have difﬁ culty using an Expected State Speciﬁ cation if the object doesn’t imple-

ment equality in a way that involves comparing the values of attributes (e.g., by

comparing the object references with each other) or if our test-speciﬁ c deﬁ nition

of equality differs from that implemented by the

equals method.

In these cases, we can still use an Expected State Speciﬁ cation if we create

a Custom Assertion (page 474) that implements test-speciﬁ c equality. Alterna-

tively, we can build the Expected State Speciﬁ cation from a class that imple-

ments our test-speciﬁ c equality. This class can either be a Test-Speciﬁ c Subclass

that overrides the equals method or a simple Data Transfer Object [CJ2EEP] that

implements equals(TheRealObjectClass other). Both of these measures are preferable

to modifying (or introducing) the equals method on the production class, as that

would be a form of Equality Pollution (see Test Logic in Production). When

the class is difﬁ cult to instantiate, we can deﬁ ne a Fake Object (page 551) that

has the necessary attributes plus an equals method that implements test-speciﬁ c

equality. These last few “tricks” are made possible by the fact that Equality

State

Veriﬁ cation

Also known as:

Expected

Object

465

Assertions usually ask the Expected State Speciﬁ cation to compare itself to the

actual result, rather than the reverse.

We can build the Expected State Speciﬁ cation either during the result veriﬁ -

cation phase of the test immediately before it is used in the Equality Assertion

or during the ﬁ xture setup phase of the test. The latter strategy allows us to use

attributes of the Expected State Speciﬁ cation as parameters passed to the SUT

or as the base for Derived Values (page 718) when building other objects in the

test ﬁ xture. This makes it easier to see the cause–effect relationship between

the ﬁ xture and the Expected State Speciﬁ cation, which in turn helps us achieve

Tests as Documentation (see page 23). It is particularly useful when the Ex-

pected State Speciﬁ cation is created out of sight of the test reader such as when

using Creation Methods to do the construction.

Motivating Example

This simple

example features a test that exercises the code that adds a line item

to an invoice. Because it contains no assertions, it is not a Self-Checking Test.

public void testInvoice_addOneLineItem_quantity1() {

// Exercise

inv.addItemQuantity(product, QUANTITY);

}

We have chosen to create the invoice and product in the setUp method, an approach

called Implicit Setup (page 424).

public void setUp() {

product = createAnonProduct();

anotherProduct = createAnonProduct();

inv = createAnonInvoice();

}

Refactoring Notes

The ﬁ rst refactoring we can do is not really a refactoring at all, because we are

changing the behavior of the tests (for the better): We introduce some assertions

that specify the expected outcome. This results in an example of Procedural

State Veriﬁ cation because we make this change within the Test Method as a

series of calls to built-in Assertion Methods.

The natural example for this pattern is not very good at illustrating the difference

between State Veriﬁ cation and Behavior Veriﬁ cation. For this purpose, refer to Behavior

Veriﬁ cation, which provides a second example of State Veriﬁ cation that is more directly

comparable.

State Verification

State

Veriﬁ cation

466

Chapter 21 Result Verification Patterns

We can further simplify the Test Method by refactoring it to use an Expected

Object. First, we build an Expected Object by constructing an object of the

expected class, or a suitable Test Double (page 522), and initializing it with

the values that were previously speciﬁ ed in the assertions. Then we replace the

series of assertions with a single Equality Assertion that compares the actual

result with an Expected Object. We may have to use a Custom Assertion if we

need test-speciﬁ c equality.

Example: Procedural State Veriﬁ cation

Here we have added the assertions to the Test Method to turn it into a Self-

Checking Test. Because several steps must be carried out to verify the expected

outcome, this test suffers from a mild case of Obscure Test.

public void testInvoice_addOneLineItem_quantity1() {

// Exercise

inv.addItemQuantity(product, QUANTITY);

// Verify

List lineItems = inv.getLineItems();

assertEquals("number of items", lineItems.size(), 1);

// Verify only item

LineItem actual = (LineItem) lineItems.get(0);

assertEquals(inv, actual.getInv());

assertEquals(product, actual.getProd());

assertEquals(QUANTITY, actual.getQuantity());

}

Example: Expected Object

In this simpliﬁ ed version of the test, we use the Expected Object with a single

Equality Assertion instead of a series of assertions on individual attributes:

public void testInvoice_addLineItem1() {

LineItem expItem = new LineItem(inv, product, QUANTITY);

// Exercise

inv.addItemQuantity( expItem.getProd(), expItem.getQuantity());

// Verify

List lineItems = inv.getLineItems();

assertEquals("number of items", lineItems.size(), 1);

LineItem actual = (LineItem) lineItems.get(0);

assertEquals("Item", expItem, actual);

}

State

Veriﬁ cation

467

Because we are also using some of the attributes as arguments of the SUT, we

have chosen to build the Expected Object during the ﬁ xture setup phase of the

test and to use the attributes of the Expected Object as the SUT arguments.

State Verification

State

Veriﬁ cation