Meszaros G. xUnit Test Patterns Refactoring Test Code

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

738

allocating the resource in this identiﬁ er, you will have fewer problems

ﬁ nding tests that do not properly release their resources.

Implementation Notes

We make the name of any resources used by a test unique across all tests by using a

Distinct Generated Value (see Generated Value on page 723) as part of the

name. Ideally, the name should include the name of the test that “owns” the

resource. To avoid Interacting Tests (see Erratic Test on page 228), we include a

time stamp in the name of any resources created by the tests and use Automated

Teardown (page 503) to delete those resources at the end of the test.

Minimize Data

The test ﬁ xture is too large, making the test hard to understand.

We remove things from the ﬁ xture until we have a Minimal Fixture.

From [RTC]:

Minimize the data that is set up in ﬁ xtures to the bare essentials. This will

have two advantages: (1) It makes them more suitable as documentation,

and (2) your tests will be less sensitive to changes.

Implementation Notes

Reducing the data in our test ﬁ xture to the bare minimum results in a Minimal Fix-

ture (page 302) that helps the tests achieve Tests as Documentation (see page 23).

How we do this depends on how our Test Methods (page 348) are organized into

Testcase Classes (page 373).

When our Test Methods are organized via the Testcase Class per Fixture pat-

tern (page 631) and we believe we have a General Fixture (see Obscure Test on

page 186), we can remove the ﬁ xture setup logic for any parts of the ﬁ xture that

we suspect are not used by the tests. It is best to remove this logic incrementally

so that if a test fails, we can undo our most recent change and try again.

When our Test Methods are organized as a Testcase Class per Feature (page 624)

or a Testcase Class per Class (page 617), Minimize Data may also involve copying

ﬁ xture setup logic from the setUp method of a Testcase Class or Setup Decora-

tor (page 447) into each test that needs the ﬁ xture. Assuming the collection of

Also known as:

Reduce Data

Minimize

Data

Appendix A Test Refactorings

739

objects in the Shared Fixture (page 317) is overkill for any one test, we can

use a series of Extract Method [Fowler] refactorings to create a set of Creation

Methods (page 415), which we then call from the tests. Next, we remove the

calls to the Creation Methods from the setUp method and put them into only

those Test Methods that require that part of the original ﬁ xture. The ﬁ nal step

would be to convert any ﬁ xture-holding instance variables into local variables.

Replace Dependency with Test Double

The dependencies of an object being tested get in the way of running tests.

Break the dependency by replacing a depended-on component

with a Test Double.

Implementation Notes

The ﬁ rst step is to choose the form of dependency substitution. Dependency

Injection (page 678) is the best option for unit tests, whereas Dependency Look-

up (page 686) often works better for customer tests. We then refactor the SUT

to support this choice or design the capability into the SUT as we do test-driven

development. The next decision is whether to use a Fake Object (page 551), a

Test Stub (page 529), a Test Spy (page 538), or a Mock Object (page 544) based

on how the Test Double will be used by the test. This decision is described in

Chapter 11, Using Test Doubles.

If we are using a Test Stub or Mock Object, we must decide whether we

want to use a Hard-Coded Test Double (page 568) or a Conﬁ gurable Test

Double (page 558). The trade-offs are discussed in Chapter 11 and in the

detailed descriptions of the patterns. That decision then dictates the shape of

our test—for example, Tests that use Mock Objects are more “front-loaded”

by the construction of the Mock Object.

Finally, we modify our test to construct, optionally conﬁ gure, and then install

the Mock Object. We may also have to add a call to the veriﬁ cation method for

some kinds of Mock Objects. In statically typed languages, we may have to do

an Extract Interface [Fowler] refactoring before we can introduce the fake imple-

mentation. We then use this interface as the type of the variable that holds the

reference to the substitutable dependency.

Replace Dependency with Test Double

Replace

Dependency

with Test

Double

740

Setup External Resource

The SUT depends on the contents of an external resource that is

acting as a Mystery Guest in our test.

Create an external resource within the ﬁ xture setup logic of

the test rather than using a predeﬁ ned resource.

From [RTC]:

If it is necessary for a test to rely on external resources, such as directories,

databases, or ﬁ les, make sure the test that uses them explicitly creates

or allocates these resources before testing, and releases them when done

(take precautions to ensure the resource is also released when tests fail).

Implementation Notes

When our SUT must use an external resource such as a ﬁ le and we absolutely,

positively cannot replace the access mechanism with a Test Stub (page 529) or Fake

Object (page 551), we may need to live with the fact that we have to use an external

resource. The problems with external resources are obvious: The test reader can-

not tell what they contain; those resources may disappear unexpectedly, causing

tests to fail because of Resource Optimism (see Erratic Test on page 228); and the

resources may result in Interacting Tests (see Erratic Test) and Test Run Wars (see

Erratic Test). Setup External Resource does not help us with the last problem but

it does avoid the problems of a Mystery Guest (see Obscure Test on page 186) and

Resource Optimism.

To implement the Setup External Resource refactoring, we simply pull the

contents of the external resource into our Test Method (page 348), setUp method,

or a Test Utility Method (page 599) called by them. Using the contents we con-

struct the external resource within our test code, thereby making it evident to the

test reader exactly what the test depends on. This approach also guarantees that

the resource exists because we create it in every test run.

Setup

External

Resource

Appendix A Test Refactorings

Appendix B

xUnit Terminology

Mocks, Fakes, Stubs, and Dummies

Are you confused about what someone means when that individual says “test

stub” or “mock object”? Do you sometimes feel that the person you are talking

to is using a very different deﬁ nition? Well, you are not alone!

The terminology for the various kinds of Test Doubles (page 522) is confusing

and inconsistent. Different authors use different terms to mean the same thing.

And sometimes they mean different things even when they use the same term!

Ouch! (See the sidebar “What’s in a (Pattern) Name?” on page 576 for why I

think names are important.)

Part of my reason for writing this book was to try to establish some consistency

in the terminology, thereby giving people a set of names with clear deﬁ nitions of

what they mean. In this appendix, I provide a list of the current sources and cross-

reference the terminology they use with the terminology used in this book.

Role Descriptions

The table on page 742 is a summary of what I mean by each of the major Test

Double pattern names.

Mocks,

Fakes, Stubs,

and

Dummies

741

742

Role

Descriptions

Appendix B xUnit Terminology

Pattern Purpose Has Behavior Injects Indirect Handles Indirect Values Provided Examples

Inputs into SUT Outputs of SUT by Test(er)

Test Double Generic name

(page 522) for family

Dummy Object Attribute or No No, never No, never No Null,

(page 728) method parameter called called “Ignored String,”

new Object()

Test Stub Verify indirect Yes Yes Ignores them Inputs

(page 529) inputs of SUT

Test Spy Verify indirect Yes Optional Captures them Inputs (optional)

(page 538) outputs of SUT for later

veriﬁ cation

Mock Object Verify indirect Yes Optional Veriﬁ es Inputs (optional)

(page 544) outputs of SUT correctness and expected

against outputs.

expectations

Fake Object Run Yes No Uses them None In-memory

(page 551) (unrunnable) database

tests (faster) emulator

Temporary Stand in for Yes No Uses them None In-memory

Test Stub procedural code database

(see Test Stub) not yet written emulator

743

Terminology Cross-Reference

The following table lists some sources of conﬂ icting deﬁ nitions just to make it

clear what the mapping is to the pattern names used in this book.

• Unit Testing with Java [UTwJ] uses the term “Dummy Object” to refer

to what this book calls a “Fake Object.”

• Pragmatic Unit Testing [PUT] describes a “Stub” as an empty imple-

mentation of a method. This is a common interpretation in the proce-

dural world; in the object world, however, it is typically called a Null

Object [PLOPD3].

• Some of the early Mock Objects literature could be interpreted to equate

a “Stub” with a “Mock Object.” The distinction between the two has since

been clariﬁ ed in [MRNO] and [MAS].

Sources and Names Used in Them

Pattern Astels Beck Feathers Fowler jMock UTWJ OMG Pragmatic Recipes

Test Double or

Double stand-in

Dummy Stub Dummy Stub

Object

Test Fake Fake Stub Stub Dummy Mock Fake

Stub

Test Spy Dummy Spy

Mock Mock Mock Mock Mock Mock Mock Mock

Object

Fake Dummy

Object

Tempo- Stub

rary

Test

Stub

OMG’s Stub

CORBA

Stub

Terminology Cross-Reference

Terminology

Cross-

Reference

744

• The CORBA standard

and other remote-procedure call speciﬁ cations

use the terms “stubs” and “skeletons” to refer to the automatically

generated code for the near- and far-end implementations of a remote

interface deﬁ ned in IDL. (I’ve included this information here because it

is another use of a term that is commonly used in the TDD and auto-

mated developer testing community.)

The sources quoted in the preceding table are provided here:

Source Description Citation Publisher

Astels Book: Test-Driven Development [TDD-APG] Prentice Hall

Beck Book: Test-Driven Development [TDD-BE] Addison-Wesley

Feathers Book: Working Effectively with [WEwLC] Prentice Hall

Legacy Code

Fowler Blog: Mocks Aren’t Stubs [MAS] martinfowler.com

jMock Paper: Mock Roles, Not Objects [MRNO] ACM (OOPSLA)

UTWJ Book: Unit Testing in Java [UTwJ] Morgan

Kaufmann

OMG Object Management Group’s OMG

CORBA speciﬁ cations

Pragmatic Book: Pragmatic Unit Testing [PUT] Pragmatic Pro-

with NUnit grammers

Recipes Book: JUnit Recipes Manning

xUnit Terminology Cross-Reference

The following table maps the terminology used in this book to the terminology

used by speciﬁ c members of the xUnit family. This list is not intended to be

exhaustive but rather is meant to illustrate the adaptations of the standard xUnit

terminology to the idioms and culture of each language and community.

CORBA is an acronym for Common Object Request Broker Architecture. This

standard is defined by the Object Management Group.

xUnit

Terminology

Cross-

Reference

Appendix B xUnit Terminology

745

xUnit Terminology Cross-Reference

xUnit

Terminology

Cross-

Reference

Continued...

Tool Book Term

Language xUnit Testcase Test Suite Test Fixture Fixture Suite Suite Expected

Member Class Factory Method setup teardown Fixture Fixture Exception

Setup Teardown Test

Java 1.4 JUnit 3.8.2 Subclass of static suite() testXxx() setUp() tearDown() Not Not Subclass of

TestCase applicable applicable Expected

Exception Test

Java 5 JUnit 4.0+ import org. static suite() @Test @Before @After @Before @After @Exception

junit.Test Class Class

.NET CsUnit [TestFixture] [Suite] [Test] [SetUp] [TearDown] Not Not [Expected

applicable applicable Exception()]

.NET NUnit 2.0 [TestFixture] [Suite] [Test] [SetUp] [TearDown] Not Not [Expected

applicable applicable Exception()]

.NET NUnit 2.1+ [TestFixture] [Suite] [Test] [SetUp] [TearDown] [Test [TestFixture [Expected

Fixture TearDown] Exception()]

SetUp]

.NET MbUnit 2.0 [TestFixture] [Suite] [Test] [SetUp] [TearDown] [Fixture [Fixture [Expected

Setup] Teardown] Exception()]

.NET MSTest [TestClass] Not [Test [Test [Test [Class [Class [Expected

applicable Method] Initialize] Cleanup] Initialize] Cleanup] Exception()]

PHP PHPUnit Subclass of static suite() testXxx() setUp() tearDown() Not Not Subclass of

TestCase applicable applicable Expected

Exception Test

746

xUnit

Terminology

Cross-

Reference

Appendix B xUnit Terminology

Tool Book Term

Language xUnit Testcase Test Suite Test Fixture Fixture Suite Suite Expected

Member Class Factory Method Setup Teardown Fixture Fixture Exception

Teardown Test

Python PyUnit Subclass of Test testXxx setUp tearDown Not Not assert raise

unittest. Loader() applicable applicable

TestCase

Ruby Test::Unit Subclass of Classname. testXxx() setup() teardown Not Not assert_raise

Test::Unit:: suite() applicable applicable

TestCase

Smalltalk SUnit Superclass: TestSuite testXxx setUp tearDown To be To be should:raise:

TestCase named: determined determined

VB 6 VbUnit Implements Implements TestXxx() IFixture_ IFixture_ IFixture IFixture on error...

IFixture ISuite Setup() TearDown Frame_ Frame_

Create() Destroy

SAP ABAP ABAP Unit FOR Automatic Any setup teardown class_setup class_ To be

TESTING teardown determined

Appendix C

xUnit Family Members

This (incomplete) list of members of the xUnit family of test automation

frameworks is included here to illustrate the diversity of the family and the

extent to which automated unit testing is supported in various programming

languages. This appendix also includes comments about speciﬁ c capabilities of

some members of the family. A much more complete and up-to-date list can be

found at http://xprogramming.com/software.htm.

ABAP Object Unit

The member of the xUnit family for SAP’s ABAP programming language. ABAP

Object Unit is more or less a direct port of JUnit to ABAP except for the fact that

it cannot catch exceptions encountered within the system under test (SUT).

ABAP Object Unit is available for download at http://www.abapunittests.

com, along with articles about unit testing in ABAP. See ABAP Unit for versions

of SAP/ABAP starting with 6.40.

ABAP Unit

The member of the xUnit family for versions of SAP’s ABAP programming lan-

guage starting with Basis version 6.40 (NetWeaver 2004s). The most notable

aspect of ABAP Unit is its special support that allows tests to be stripped from

the code as the code is “transported” from the acceptance test environment to

the production environment.

ABAP Unit is available directly from SAP AG as part of the NetWeaver 2004s

development tools. More information on unit testing in ABAP is available in

the SAP documentation and from http://www.abapunittests.com. See ABAP

Object Unit for versions of SAP/ABAP prior to Basis version 6.40 (NetWeaver

2004s).

xUnit Family

Members

747