Meszaros G. xUnit Test Patterns Refactoring Test Code

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

Chapter 6 Test Automation Strategy

Figure 6.7 A round-trip test interacts with the SUT only via the front door. The

test on the right replaces a DOC with a Fake Object to improve its repeatability

or performance.

Figure 6.8 A layer-crossing test can interact with the SUT via a “back door.”

The test on the left controls the SUT’s indirect inputs using a Test Stub. The test

on the right veriﬁ es its indirect outputs using a Mock Object.

DOC

SUT

FakeComponentTest

testMethod_1

testMethod_2

RealComponentTest

testMethod_2

Fake

Object

Installation

SUT

Creation

testMethod_1

DOC

SUT

FakeComponentTest

testMethod_1

testMethod_2

RealComponentTest

testMethod_2

Fake

Object

Installation

SUT

Creation

testMethod_1

IndirectOutputTest

DOC

SUT

IndirectInputTest

testMethod_1

testMethod_2

testMethod_1

testMethod_2

Test Stub

Mock Object

SUT

Indirect

Outputs

Indirect

Inputs

Installation

Creation

and

Configuration

Installation

Creation

and

Configuration

IndirectOutputTest

DOC

SUT

IndirectInputTest

testMethod_1

testMethod_2

testMethod_1

testMethod_2

Test Stub

Mock Object

SUT

Indirect

Outputs

Indirect

Inputs

Installation

Creation

and

Configuration

Installation

Creation

and

Configuration

In Figure 6.8, the test on the right uses a Mock Object that stands in for the DOC

as the observation point. The test on the left uses a Test Stub that stands in for

the DOC as a control point. Testing in this style implies a Layered Architecture

[DDD, PEAA, WWW], which in turn opens the door to using Layer Tests (page 337)

to test each layer of the architecture independently (Figure 6.9). An even more

general concept is the use of Component Tests (see Layer Test) to test each com-

ponent within a layer independently.

Figure 6.9 A pair of Layer Tests each testing a different layer of the system.

Each layer of a layered architecture can be tested independently using a distinct

set of Layer Tests. This ensures good separation of concerns, and the tests

reinforce the layered architecture.

Whenever we want to write layer-crossing tests, we need to ensure that we have

built in a substitutable dependency mechanism for any components on which

the SUT depends but that we want to test independently. The leading contend-

ers include any of the variations of Dependency Injection (Figure 6.10) or some

form of Dependency Lookup such as Object Factory or Service Locator. These

dependency substitution mechanisms can be hand-coded or we can use an in-

version of control (IOC) framework if one is available in our programming

environment. The fallback plan is to use a Test-Speciﬁ c Subclass (page 579)

of the SUT or the DOC in question. This subclass can be used to override the

dependency access or construction mechanism within the SUT or to replace the

behavior of the DOC with test-speciﬁ c behavior.

DOC

Layer n

LayernTestcaseClass

testMethod_1

testMethod_2

Layer1TestcaseClass

testMethod_1

testMethod_2

Layer 1

Test Double

DOC

Layer n

LayernTestcaseClass

testMethod_1

testMethod_2

Layer1TestcaseClass

testMethod_1

testMethod_2

Layer 1

Test Double

How Do We Ensure Testability?

Chapter 6 Test Automation Strategy

The “solution of last resort” is the Test Hook (page 709).

These constructs

do have utility as temporary measures that allow us to automate tests to act

as a Safety Net (page 24) while refactoring to retroﬁ t testability. We deﬁ nitely

shouldn’t make a habit of using them, however, as continued use of Test Hooks

will result in Test Logic in Production (page 217).

Figure 6.10 A Test Double being “injected” into a SUT by a test. A test can

use Dependency Injection to replace a DOC with an appropriate Test Double. The

DOC is passed to the SUT by the test as or after it has been created.

A third kind of test worth mentioning is the asynchronous test, in which the test

interacts with the SUT through real messaging. Because the responses to these

requests also come asynchronously, these tests must include some kind of inter-

process synchronization such as calls to wait. Unfortunately, the need to wait for

message responses that might never arrive can cause these tests to take much,

much longer to execute. This style of testing should be avoided at all costs in

unit and component tests.

Fortunately, the Humble Executable pattern (see Humble Object on page 695)

can remove the need to conduct unit tests this way (Figure 6.11). It involves

putting the logic that handles the incoming message into a separate class or

component, which can then be tested synchronously using either a round-trip

or layer-crossing style.

A related issue is the testing of business logic through a UI. In general, such

Indirect Testing (see Obscure Test) is a bad idea because changes to the UI code

will break tests that are trying to verify the business logic behind it. Because the

UI tends to change frequently, especially on agile projects, this strategy will

greatly increase test maintenance costs. Another reason this is a bad idea is that

These typically take the form of if (testing) then ... else ... endif.

DOC

Test

Double

Creation

SUT

Usage

Client

Exercise

Setup

Exercise

Verify

Teardown

Usage Usage

DOC

Test

Double

Creation

SUT

Usage

Client

Exercise

Setup

Exercise

Verify

Teardown

Usage Usage

UIs are inherently asynchronous. Tests that exercise the system through the UI

have to be asynchronous tests along with all the issues that come with them.

Figure 6.11 A Humble Executable making testing easier. The Humble

Executable pattern can improve the repeatability and speed of verifying logic

that would otherwise have to be veriﬁ ed via asynchronous tests.

Divide and Test

We can turn almost any Hard-to-Test Code (page 209) into easily tested code

through refactoring as long as we have enough tests in place to ensure that we

do not introduce bugs during this refactoring.

We can avoid using the UI for customer tests by writing those tests as Subcu-

taneous Tests (see Layer Test). These tests bypass the UI layer of the system and

exercise the business logic via a Service Facade [CJ2EEP] that exposes the neces-

sary synchronous interaction points to the test. The UI relies on the same facade,

enabling us to verify that the business logic works correctly even before we hook

up the UI logic. The layered architecture also enables us to test the UI logic before

the business logic is ﬁ nished; we can replace the Service Facade with a Test Double

that provides completely deterministic behavior that our tests can depend on.

This Test Double can be either hard-coded or ﬁ le driven. Either way, it should be inde-

pendent of the real implementation so that the UI tests need to know only which data to

use to evoke speciﬁ c behaviors from the Service Facade, not the logic behind it.

Fixture

Setup

Exercise

Verify

Teardown

Testable

Component

Humble

Executable

Asynchronous

Interface

Synchronous

Interface

Fixture

Setup

Exercise

Verify

Teardown

Testable

Component

Humble

Executable

Asynchronous

Interface

Synchronous

Interface

How Do We Ensure Testability?

Chapter 6 Test Automation Strategy

When conducting unit testing of nontrivial UIs,

we can use a Humble Dialog

(see Humble Object) to move the logic that makes decisions about the UI out

of the visual layer, which is difﬁ cult to test synchronously, and into a layer of

supporting objects, which can be veriﬁ ed with standard unit-testing techniques

(Figure 6.12). This approach allows the presentation logic behavior to be tested

as thoroughly as the business logic behavior.

Figure 6.12 A Humble Dialog reducing the dependency of the test on the UI

framework. The logic that controls the state of UI components can be very difﬁ cult

to test. Extracting it into a testable component leaves behind a Humble Dialog that

requires very little testing.

From a test automation strategy perspective, the key thing is to make the

decision about which test–SUT interaction styles should be used and which

ones should be avoided, and to ensure that the software is designed to support

that decision.

Any UI that contains state information or supports conditional display or enabling of

elements should be considered nontrivial.

Setup

Exercise

Verify

Teardown

Testable

GUI Logic

Component

Humble Dialog

Abc

def

ghi

OK Cancel

GUI

Frame-

work

Mock

Dialog

Setup

Exercise

Verify

Teardown

Testable

GUI Logic

Component

Humble Dialog

Abc

def

ghi

OK Cancel

GUI

Frame-

work

Mock

Dialog

What’s Next?

This concludes our introduction to the hard-to-change decisions we must make

as we settle upon our test automation strategy. Given that you are still reading,

I will assume that you have decided xUnit is an appropriate tool for doing your

test automation. The following chapters introduce the detailed patterns for im-

plementing our chosen ﬁ xture strategy, whether it involves a Fresh Fixture or a

Shared Fixture. First, we will explore the simplest case, a Transient Fresh Fixture,

in Chapter 8, Transient Fixture Management. We will then investigate the use of

persistent ﬁ xtures in Chapter 9, Persistent Fixture Management. But ﬁ rst, we must

establish the basic xUnit terminology and notation that is used throughout this

book in Chapter 7, xUnit Basics.

What’s Next?

This page intentionally left blank

Chapter 7

xUnit Basics

About This Chapter

Chapter 6, Test Automation Strategy, introduced the “hard to change” decisions

that we need to get right early in the project. The current chapter serves two

purposes. First, it introduces the xUnit terminology and diagramming notation

used throughout this book. Second, it explains how the xUnit framework oper-

ates beneath the covers and why it was built that way. This knowledge can help

the builder of a new Test Automation Framework (page 298) understand how

to port xUnit. It can also help test automaters understand how to use certain

features of xUnit.

An Introduction to xUnit

The term xUnit is how we refer to any member of the family of Test Automa-

tion Frameworks used for automating Hand-Scripted Tests (see Scripted Test

on page 285) that share the common set of features described here. Most pro-

gramming languages in widespread use today have at least one implementation

of xUnit; Hand-Scripted Tests are usually automated using the same program-

ming language as is used for building the SUT. Although this is not necessarily

the case, this strategy is usually much easier because our tests have easy access

to the SUT API. By using a programming language with which the developers

are familiar, less effort is required to learn how to automate Fully Automated

Tests (page 26).

See the sidebar “Testing Stored Procs with JUnit” (page 657) for an example of using a

testing framework in one language to test an SUT in another language.

Chapter 7 xUnit Basics

Common Features

Given that most members of the xUnit family are implemented using an object-

oriented programming language (OOPL), they are described here ﬁ rst and then

places where the non-OOPL members of the family differ are noted.

All members of the xUnit family implement a basic set of features. They all

provide a way to perform the following tasks:

• Specify a test as a Test Method (page 348)

• Specify the expected results within the test method in the form of calls

to Assertion Methods (page 362)

• Aggregate the tests into test suites that can be run as a single operation

• Run one or more tests to get a report on the results of the test run

Because many members of the xUnit family support Test Method Discovery (see

Test Discovery on page 393), we do not have to use Test Enumeration (page 399)

in these members to manually add each Test Method we want to run to a test

suite. Some members also support some form of Test Selection (page 403) to run

subsets of test methods based on some criteria.

The Bare Minimum

Here is the bare minimum we need to understand about how xUnit operates

(Figure 7.1):

• How we deﬁ ne tests using Test Methods on Testcase Classes (page 373)

• How we can build up arbitrary Suites of Suites (see Test Suite Object on

page 387)

• How we run the tests

• How we interpret the test results

Deﬁ ning Tests

Each test is represented by a Test Method that implements a single Four-Phase

Test (page 358) by following these steps:

Even those xUnit variants that don’t have an explicit Suite class or method still build

Test Suite Objects behind the scene.

• Setting up the test ﬁ xture using either In-line Setup (page 408), Delegated

Setup (page 411), or Implicit Setup (page 424)

• Exercising the SUT by interacting with methods in its public or private

interface

• Verifying that the expected outcome has occurred using calls to Assertion

Methods

• Tearing down the test ﬁ xture using either Garbage-Collected Tear-

down (page 500), In-line Teardown (page 509), Implicit Teardown (page 516),

or Automated Teardown (page 503)

Figure 7.1 The static test structure as seen by a test automater. The test

automater sees only the static structure as he or she reads or writes tests. The

test automater writes one Test Method with four distinct phases for each test in

the Testcase Class. The Test Suite Factory (see Test Enumeration) is used only

for Test Enumeration. The runtime structure (shown grayed out) is left to the

test automater’s imagination.

The most common types of tests are the Simple Success Test (see Test Method),

which veriﬁ es that the SUT has behaved correctly with valid inputs, and the

Expected Exception Test (see Test Method), which veriﬁ es that the SUT raises an

exception when used incorrectly. A special type of test, the Constructor Test (see

Test Method), veriﬁ es that the object constructor logic builds new objects cor-

rectly. Both “simple success” and “expected exception” forms of the Constructor

Test may be needed. The Test Methods that contain our test logic need to live

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Testcase

Class

testMethod_n

Test

Suite

Object

Exercise

Create

Exercise

Create

Fixture

SUT

Run

Setup

Exercise

Verify

Teardown

Suite

Test Runner

Test

Suite

Factory

Create

testMethod_1

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Testcase

Class

testMethod_n

Test

Suite

Object

Exercise

Create

Exercise

Create

Fixture

SUT

Run

Setup

Exercise

Verify

Teardown

Suite

Test Runner

Test

Suite

Factory

Create

testMethod_1

The Bare Minimum