Meszaros G. xUnit Test Patterns Refactoring Test Code

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

the bulky code we started with. It fulﬁ lls the role of Tests as Documentation

(see page 23) very well. So what did we discover that this test veriﬁ es? It con-

ﬁ rms that the line items added to an invoice are, indeed, added to the invoice

and that the extended cost is based on the product price, the customer’s dis-

count, and the quantity ordered.

Writing More Tests

It seemed like we went to a lot of effort to refactor this test to make it clearer.

Will we have to spend so much effort on every test?

I should hope not! Much of the effort here related to the discovery of which

Test Utility Methods (page 599) were required for writing the test. We deﬁ ned a

Higher-Level Language (see page 41) for testing our application. Once we have

those methods in place, writing other tests becomes much simpler. For example, if

we want to write a test that veriﬁ es that the extended cost is recalculated when we

change the quantity of a LineItem, we can reuse most of the Test Utility Methods.

public void testAddLineItem_quantityOne(){

ﬁnal BigDecimal BASE_PRICE = UNIT_PRICE;

ﬁnal BigDecimal EXTENDED_PRICE = BASE_PRICE;

// Set up ﬁxture

Customer customer = createACustomer(NO_CUST_DISCOUNT);

Invoice invoice = createInvoice(customer);

// Exercise SUT

invoice.addItemQuantity(PRODUCT, QUAN_ONE);

// Verify outcome

LineItem expected =

createLineItem( QUAN_ONE, NO_CUST_DISCOUNT,

EXTENDED_PRICE, PRODUCT, invoice);

assertContainsExactlyOneLineItem( invoice, expected );

}

public void testChangeQuantity_severalQuantity(){

ﬁnal int ORIGINAL_QUANTITY = 3;

ﬁnal int NEW_QUANTITY = 5;

ﬁnal BigDecimal BASE_PRICE =

UNIT_PRICE.multiply( new BigDecimal(NEW_QUANTITY));

ﬁnal BigDecimal EXTENDED_PRICE =

BASE_PRICE.subtract(BASE_PRICE.multiply(

CUST_DISCOUNT_PC.movePointLeft(2)));

// Set up ﬁxture

Customer customer = createACustomer(CUST_DISCOUNT_PC);

Invoice invoice = createInvoice(customer);

Product product = createAProduct( UNIT_PRICE);

invoice.addItemQuantity(product, ORIGINAL_QUANTITY);

lviii

Refactoring a Test

// Exercise SUT

invoice.changeQuantityForProduct(product, NEW_QUANTITY);

// Verify outcome

LineItem expected = createLineItem( NEW_QUANTITY,

CUST_DISCOUNT_PC, EXTENDED_PRICE, PRODUCT, invoice);

assertContainsExactlyOneLineItem( invoice, expected );

}

This test was written in about two minutes and did not require adding any new

Test Utility Methods. Contrast that with how long it would have taken to write

a completely new test in the original style. And the effort saved in writing the

tests is just part of the equation—we also need to consider the effort we saved

understanding existing tests each time we need to revisit them. Over the course

of a development project and the subsequent maintenance activity, this cost sav-

ings will really add up.

Further Compaction

Writing these additional tests revealed a few more sources of Test Code Duplication

(page 213). For example, it seems that we always create both a Customer and an

Invoice. Why not combine these two lines? Similarly, we continually deﬁ ne and

initialize the

QUANTITY and CUSTOMER_DISCOUNT_PC constants inside our test methods.

Why can’t we do these tasks just once? The Product does not seem to play any

roles in these tests; we always create it exactly the same way. Can we factor this

responsibility out, too? Certainly! We just apply an Extract Method refactoring

to each set of duplicated code to create more powerful Creation Methods.

public void testAddItemQuantity_severalQuantity_v15(){

// Set up ﬁxture

Invoice invoice = createCustomerInvoice(CUST_DISCOUNT_PC);

// Exercise SUT

invoice.addItemQuantity(PRODUCT, SEVERAL);

// Verify outcome

ﬁnal BigDecimal BASE_PRICE =

UNIT_PRICE.multiply(new BigDecimal(SEVERAL));

ﬁnal BigDecimal EXTENDED_PRICE =

BASE_PRICE.subtract(BASE_PRICE.multiply(

CUST_DISCOUNT_PC.movePointLeft(2)));

LineItem expected = createLineItem( SEVERAL,

CUST_DISCOUNT_PC, EXTENDED_PRICE, PRODUCT, invoice);

assertContainsExactlyOneLineItem(invoice, expected);

}

public void testAddLineItem_quantityOne_v2(){

ﬁnal BigDecimal BASE_PRICE = UNIT_PRICE;

ﬁnal BigDecimal EXTENDED_PRICE = BASE_PRICE;

Further Compaction

lix

// Set up ﬁxture

Invoice invoice = createCustomerInvoice(NO_CUST_DISCOUNT);

// Exercise SUT

invoice.addItemQuantity(PRODUCT, QUAN_ONE);

// Verify outcome

LineItem expected = createLineItem( SEVERAL,

CUST_DISCOUNT_PC, EXTENDED_PRICE, PRODUCT, invoice);

assertContainsExactlyOneLineItem( invoice, expected );

}

public void testChangeQuantity_severalQuantity_V2(){

ﬁnal int NEW_QUANTITY = SEVERAL + 2;

ﬁnal BigDecimal BASE_PRICE =

UNIT_PRICE.multiply( new BigDecimal(NEW_QUANTITY));

ﬁnal BigDecimal EXTENDED_PRICE =

BASE_PRICE.subtract(BASE_PRICE.multiply(

CUST_DISCOUNT_PC.movePointLeft(2)));

// Set up ﬁxture

Invoice invoice = createCustomerInvoice(CUST_DISCOUNT_PC);

invoice.addItemQuantity(PRODUCT, SEVERAL);

// Exercise SUT

invoice.changeQuantityForProduct(PRODUCT, NEW_QUANTITY);

// Verify outcome

LineItem expected = createLineItem( NEW_QUANTITY,

CUST_DISCOUNT_PC, EXTENDED_PRICE, PRODUCT, invoice);

assertContainsExactlyOneLineItem( invoice, expected );

}

We have now reduced the number of lines of code we need to understand from 35

statements in the original test to just 6 statements.

We are left with just a bit more

than one sixth of the original code to maintain! We could go further by factoring

out the ﬁ xture setup into a setUp method, but that effort would be worthwhile only

if a lot of tests needed the same Customer/Discount/Invoice conﬁ guration. If we

wanted to reuse these Test Utility Methods from other Testcase Classes (page 373),

we could use an Extract Superclass [Fowler] refactoring to create a Testcase Super-

class (page 638), and then use a Pull Up Method [Fowler] refactoring to move the

Test Utility Methods to it so they can be reused.

Ignoring wrapped lines, we have 6 executable statements surrounded by the two lines

of method declarations/end.

Refactoring a Test

PART I

The Narratives

This page intentionally left blank

Chapter 1

A Brief Tour

About This Chapter

There are a lot of principles, patterns, and smells in this book—and even more pat-

terns that couldn’t ﬁ t into the book. Do you need to learn them all? Do you need

to use them all? Probably not! This chapter provides an abbreviated introduction

to the bulk of the material in the entire book. You can use it as a quick tour of the

material before diving into particular patterns or smells of interest. You can also

use it as a warm-up before exploring the more detailed narrative chapters.

The Simplest Test Automation Strategy That Could

Possibly Work

There is a simple test automation strategy that will work for many, many

projects. This section describes this minimal test strategy. The principles, pat-

terns, and smells referenced here are the core patterns that will serve us well in

the long run. If we learn to apply them effectively, we will probably be success-

ful in our test automation endeavors. If we ﬁ nd that we really cannot make the

minimal test strategy work on our project by using these patterns, we can fall

back to the alternative patterns listed in the full descriptions of these patterns

and in the other narratives.

I have laid out this simple strategy in ﬁ ve parts:

• Development Process: How the process we use to develop the code

affects our tests.

• Customer Tests: The ﬁ rst tests we should write as the ultimate deﬁ ni-

tion of “what done looks like.”

Chapter 1 A Brief Tour

• Unit Tests: The tests that help our design emerge incrementally and

ensure that all our code is tested.

• Design for Testability: The patterns that make our design easier to test,

thereby reducing the cost of test automation.

• Test Organization: How we can organize our Test Methods (page 348)

and Testcase Classes (page 373).

Development Process

First things ﬁ rst: When do we write our tests? Writing tests before we write our

software has several beneﬁ ts. In particular, it gives us an agreed-upon deﬁ nition

of what success looks like.

When doing new software development, we strive to do storytest-driven

development by ﬁ rst automating a suite of customer tests that verify the func-

tionality provided by the application. To ensure that all of our software is tested,

we augment these tests with a suite of unit tests that verify all code paths or, at a

minimum, all the code paths that are not covered by the customer tests. We can

use code coverage tools to discover which code is not being exercised and then

retroﬁ t unit tests to accommodate the untested code.

By organizing the unit tests and customer tests into separate test suites, we

ensure that we can run just the unit tests or just the customer tests if neces-

sary. The unit tests should always pass before we check them in; this is what

we mean by the phrase “keep the bar green.” To ensure that the unit tests are

run frequently, we can include them in the Smoke Tests [SCM] that are run as

part of the Integration Build [SCM]. Although many of the customer tests will

fail until the corresponding functionality is built, it is nevertheless useful to

run all the passing customer tests as part of the integration build phase—but

only if this step does not slow the build down too much. In that case, we can

leave them out of the check-in build and simply run them every night.

We can ensure that our software is testable by doing test-driven development

(TDD). That is, we write the unit tests before we write the code, and we use

the tests to help us deﬁ ne the software’s design. This strategy helps concentrate

all the business logic that needs veriﬁ cation in well-deﬁ ned objects that can be

tested independently of the database. Although we should also have unit tests

If our customer cannot deﬁ ne the tests before we have built the software, we have every

reason to be worried!

We will likely ﬁ nd fewer Missing Unit Tests (see Production Bugs on page 268) when

we practice test-driven development than if we adopt a “test last” policy. Even so, there

is still value in running the code coverage tools with TDD.

for the data access layer and the database, we try to keep the dependency on the

database to a minimum in the unit tests for the business logic.

Customer Tests

The customer tests should capture the essence of what the customer wants

the system to do. Enumerating the tests before we begin their development is

an important step whether or not we actually automate the tests, because it

helps the development team understand what the customer really wants; these

tests deﬁ ne what success looks like. We can automate the tests using Scripted

Tests (page 285) or Data-Driven Tests (page 288) depending on who is pre-

paring the tests; customers can take part in test automation if we use Data-

Driven Tests. On rare occasions, we might even use Recorded Tests (page 278)

for regression testing an existing application while we refactor the application

to improve its testability. Of course, we usually discard these tests once we have

developed other tests that cover the functionality, because Recorded Tests tend

to be Fragile Tests (page 239).

During their development, we strive to make our customer tests represen-

tative of how the system is really used. Unfortunately, this goal often conﬂ icts

with attempts to keep the tests from becoming too long, because long tests

are often Obscure Tests (page 186) and tend not to provide very good Defect

Localization (see page 22) when they fail partway through the test. We can also

use well-written Tests as Documentation (see page 23) to identify how the system

is supposed to work. To keep the tests simple and easy to understand, we can

bypass the user interface by performing Subcutaneous Testing (see Layer Test on

page 337) against one or more Service Facades [CJ2EEP]. Service Facades encap-

sulate all of the business logic behind a simple interface that is also used by the

presentation layer.

Every test needs a starting point. As part of our testing plan, we take care

that each test sets up this starting point, known as the test ﬁ xture, each time

the test is run. This Fresh Fixture (page 311) helps us avoid Interacting Tests

(see Erratic Test on page 228) by ensuring that tests do not depend on anything

they did not set up themselves. We avoid using a Shared Fixture (page 317),

unless it is an Immutable Shared Fixture, to avoid starting down the slippery

slope to Erratic Tests.

If our application normally interacts with other applications, we may need

to isolate it from any applications that we do not have in our development en-

vironment by using some form of Test Double (page 522) for the objects that

act as interfaces to the other applications. If the tests run too slowly because of

database access or other slow components, we can replace them with functionally

The Simplest Test Automation Strategy That Could Possibly Work

equivalent Fake Objects (page 551) to speed up our tests, thereby encouraging

developers to run them more regularly. If at all possible, we avoid using Chained

Tests (page 454)—they are just the test smell Interacting Tests in disguise.

Unit Tests

For our unit tests to be effective, each one should be a Fully Automated Test

(page 26) that does a round-trip test against a class through its public interface.

We can strive for Defect Localization by ensuring that each test is a Single-

Condition Test (see page 45) that exercises a single method or object in a single

scenario. We should also write our tests so that each part of the Four-Phase

Test (page 358) is easily recognizable, which enables us to use the Tests as Docu-

mentation.

We use a Fresh Fixture strategy so that we do not have to worry about In-

teracting Tests or ﬁ xture teardown. We begin by creating a Testcase Class for

each class we are testing (see Testcase Class per Class on page 617), with each

test being a separate Test Method on that class. Each Test Method can use Del-

egated Setup (page 411) to build a Minimal Fixture (page 302) that makes the

tests easily understood by calling well-named Creation Methods (page 415) to

build the objects required for each test ﬁ xture.

To make the tests self-checking (Self-Checking Test; see page 26), we

express the expected outcome of each test as one or more Expected Objects

(see State Veriﬁ cation on page 462) and compare them with the actual objects

returned by the system under test (SUT) using the built-in Equality Assertions

(see Assertion Method on page 362) or Custom Assertions (page 474) that

implement our own test-speciﬁ c equality. If several tests are expected to result

in the same outcome, we can factor out the veriﬁ cation logic into an outcome-

describing Veriﬁ cation Method (see Custom Assertion) that the test reader can

more easily recognize.

If we have Untested Code (see Production Bugs on page 268) because we

cannot ﬁ nd a way to execute the path through the code, we can use a Test

Stub (page 529) to gain control of the indirect inputs of the SUT. If there

are Untested Requirements (see Production Bugs) because not all of the

system’s behavior is observable via its public interface, we can use a Mock

Object (page 544) to intercept and verify the indirect outputs of the SUT.

Chapter 1 A Brief Tour

Design for Testability

Automated testing is much simpler if we adopt a Layered Architecture [DDD,

PEAA, WWW]. At a minimum, we should separate our business logic from the

database and the user interface, thereby enabling us to test it easily using either

Subcutaneous Tests or Service Layer Tests (see Layer Test). We can minimize any

dependence on a Database Sandbox (page 650) by doing most—if not all—of

our testing using in-memory objects only. This scheme lets the runtime environ-

ment implement Garbage-Collected Teardown (page 500) for us automatically,

meaning that we can avoid writing potentially complex, error-prone teardown

logic (a sure source of Resource Leakage; see Erratic Test). It also helps us avoid

Slow Tests (page 253) by reducing disk I/O, which is much slower than memory

manipulation.

If we are building a GUI, we should try to keep the complex GUI logic out

of the visual classes. Using a Humble Dialog (see Humble Object on page 695)

that delegates all decision making to nonvisual classes allows us to write unit

tests for the GUI logic (e.g., enabling/disabling buttons) without having to

instantiate the graphical objects or the framework on which they depend.

If the application is complex enough or if we are expected to build compo-

nents that will be reused by other projects, we can augment the unit tests with

component tests that verify the behavior of each component in isolation. We

will probably need to use Test Doubles to replace any components on which

our component depends. To install the Test Doubles at runtime, we can use

either Dependency Injection (page 678), Dependency Lookup (page 686), or a

Subclassed Singleton (see Test-Speciﬁ c Subclass on page 579).

Test Organization

If we end up with too many Test Methods on our Testcase Class, we can con-

sider splitting the class based on either the methods (or features) veriﬁ ed by the

tests or their ﬁ xture needs. These patterns are called Testcase Class per Fea-

ture (page 624) and Testcase Class per Fixture (page 631), respectively. Testcase

Class per Fixture allows us to move all of the ﬁ xture setup code into the setUp

method, an approach called Implicit Setup (page 424). We can then aggregate

the Test Suite Objects (page 387) for the resulting Testcase Classes into a single

Test Suite Object, resulting in a Suite of Suites (see Test Suite Object) containing

all the tests from the original Testcase Class. This Test Suite Object can, in turn,

be added to the Test Suite Object for the containing package or namespace. We

can then run all of the tests or just a subset that is relevant to the area of the

software in which we are working.

The Simplest Test Automation Strategy That Could Possibly Work