Meszaros G. xUnit Test Patterns Refactoring Test Code

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

The Dir['tests/*.rb'] returns a collection of ﬁ les over which the each method iter-

ates with the block containing “require each” to implement Testcase Class Dis-

covery. The Ruby interpreter and Test::Unit ﬁ nish the job by doing Test Method

Discovery on each required class.

Test

Discovery

398

Chapter 19 xUnit Basics Patterns

Test Enumeration

How does the Test Runner know which tests to run?

The test automater manually writes the code that enumerates all tests that

belong to the test suite.

Given that we have written a number of Test Methods (page 348) on one or

more Testcase Classes (page 373), we need to give the Test Runner (page 377)

some way to ﬁ nd the tests. Test Enumeration is the way we do so when we lack

support for Test Discovery (page 393).

How It Works

The test automater manually writes the code that enumerates all Test Methods

that belong to the test suite and/or all Test Suite Objects (page 387) that belong

to a Suite of Suites (see Test Suite Object). This is typically done by implement-

ing the method suite either on a Testcase Class for Test Method Enumeration or

on a Test Suite Factory for Test Suite Enumeration.

When to Use It

We need to use Test Enumeration if our Test Automation Framework (page 298)

does not support Test Discovery. We can also choose to use Test Enumeration

testMethod_n

Testcase

Class

Create

Testcase

Object

Testcase

Object

testMethod_1

testMethod_n

Test

Suite

Object

Exercise

Create

Fixture

SUT

Run

Suite

Test Runner

Test

Suite

Factory

Create

testMethod_n

Testcase

Class

Create

Testcase

Object

Testcase

Object

testMethod_1

testMethod_n

Test

Suite

Object

Exercise

Create

Fixture

SUT

Run

Suite

Test Runner

Test

Suite

Factory

Create

Test Enumeration

Test

Enumeration

399

Also known as:

Test Suite

Factory

when we wish to deﬁ ne a Named Test Suite (page 592) that consists of a subset

of tests

chosen from other test suites and the framework does not support Test

Selection (page 403).

Many members of the xUnit family support Test Discovery at the Test Method

level but force us to use Test Enumeration at the Testcase Class level.

Implementation Notes

Building the Suite of Suites to be executed by the Test Runner involves two steps.

First, we must ﬁ nd all Test Methods to be included in each Test Suite Object.

Second, we must ﬁ nd all Test Suite Objects to be included in the test run, albeit

not necessarily in this order. Each of these steps may be done manually via

Test Method Enumeration and Test Suite Enumeration or automatically via Test

Method Discovery (see Test Discovery) and Testcase Class Discovery (see Test

Discovery). When done manually, we typically use a “Test Suite Factory” that

returns the Test Suite Object.

Variation: Test Suite Enumeration

Many members of the xUnit family require that we provide a Test Suite Factory

that builds the top-level Suite of Suites (often called “AllTests”) as means to

specify which Test Suite Objects we would like to include in a test run. We do

so by providing a class method on a factory class; this Factory Method [GOF]

is called suite in most members of the xUnit family. Inside the suite method we

use calls to methods such as addTest to add each nested Test Suite Object to the

suite we are building.

Although this approach is fairly ﬂ exible, it can result in Lost Tests (see

Production Bugs on page 268). The alternative is to let the development tools

build the AllTests Suite (see Named Test Suite) automatically or to use a Test

Runner that ﬁ nds all test suites in a ﬁ le system directory automatically. For

example, NUnit provides a built-in mechanism that implements Testcase Class

Discovery at the assembly level. We can also use third-party tools such as Ant

to ﬁ nd all Testcase Class ﬁ les in a directory structure.

Even in statically typed languages such as Java, the Test Suite Factory (see

Test Enumeration on page 399) does not need to subclass a speciﬁ c class or

implement a speciﬁ c interface. Instead, the only dependencies are on the generic

Test Suite Object class it returns and the Testcase Classes or Test Suite Factories

it asks for the nested suites.

A Smoke Test [SCM] suite is a good example.

Test

Enumeration

400

Chapter 19 xUnit Basics Patterns

Variation: Test Method Enumeration

Many members of the xUnit family now support Test Method Discovery. If we

happen to be using a version that does not, we need to ﬁ nd all Test Methods in a

Testcase Class, turn them into Testcase Objects (page 382), and put them into a

Test Suite Object. We implement Test Method Enumeration by providing a class

method, typically called suite, on the Testcase Class itself.

The capability to construct an object that calls an arbitrary method is often in-

herited from the Test Automation Framework via a Testcase Superclass (page 638)

or mixed in via a class attribute or Include directive. In some members of the xUnit

family, this Pluggable Behavior [SBPP] capability is provided by a separate class

(see the CppUnit example below).

Variation: Direct Test Method Invocation

In the pure procedural world where we cannot treat a Test Method as an object

or data item, we have no choice but to hand-code a Test Suite Procedure (see

Test Suite Object) for each test suite. This procedure then calls each Test Method

(or other Test Suite Procedures) one by one.

Example: Test Method Enumeration in CppUnit

Early versions of most xUnit family members required that the test automater

add each Test Method manually. Those versions that cannot use reﬂ ection still

have this requirement. Here is an example from an older version of CppUnit

that uses this approach:

public:

static CppUnit::Test *suite()

{

CppUnit::TestSuite *suite =

new CppUnit::TestSuite( "ComplexNumberTest" );

suite>addTest(

new CppUnit::TestCaller<ComplexNumberTest>(

"testEquality",

&ComplexNumberTest::testEquality ) );

suite>addTest(

new CppUnit::TestCaller<ComplexNumberTest>(

"testAddition",

&ComplexNumberTest::testAddition ) );

return suite;

}

This example also illustrates how CppUnit wraps each Test Method with an

instance of a class (TestCaller) to turn it into a Testcase Object.

Test Enumeration

Test

Enumeration

401

Example: Test Method Invocation (Hard-Coded)

The following example is from a test suite for a program written in VBA (Visual

Basic for Applications, the macro language used in Microsoft Ofﬁ ce products),

which lacks support for objects:

Sub TestAllStoryMacros()

Call TestActivitySorting

Call TestStoryHiding

Call ReportSuccess("All Story Macros")

End Sub

Example: Test Suite Enumeration

We can use Test Suite Enumeration when the Test Automation Framework does

not support Test Discovery or when we want to deﬁ ne a Named Test Suite that

includes only a subset of the tests.

The main drawback of using Test Suite Enumeration for running all tests is

the potential for Lost Tests if we forget to include a new test suite in the AllTests

Suite. This risk can be reduced by paying attention to the number of tests that

were run when we ﬁ rst checked out the code and ensuring that the number run

just before check-in goes up by the number of new tests we added.

public class AllTests {

public static Test suite() {

TestSuite suite = new TestSuite("Test for allJunitTests");

//$JUnit-BEGIN$

suite.addTestSuite(

com.clrstream.camug.example.test.InvoiceTest.class);

suite.addTest(com.clrstream.ex7.test.AllTests.suite());

suite.addTest(com.clrstream.ex8.test.AllTests.suite());

suite.addTestSuite(

com.xunitpatterns.guardassertion.Example.class);

//$JUnit-END$

return suite;

}

In this example, we take advantage of the IDE’s ability to (re)generate the AllTests

suite for us. (Eclipse will regenerate the code between the two marker comments

whenever we request it to do so.) We still need to remember to regenerate the

suite occasionally, but this approach goes a long way toward avoiding Lost Tests

in the absence of Test Discovery.

Test

Enumeration

402

Chapter 19 xUnit Basics Patterns

Test Selection

How does the Test Runner know which tests to run?

The Test Automation Framework selects the Test Methods to be run at

runtime based on attributes of the tests.

Given that we have written a number of Test Methods (page 348) on one or more

Testcase Classes (page 373), we need to give the Test Runner (page 377) some way

to ﬁ nd those tests. Test Selection is a way to pick subsets of tests dynamically.

How It Works

The test automater speciﬁ es the subset of tests to be run when invoking the Test

Runner by providing test selection criteria. These selection criteria may be based

on implicit or explicit attributes of the Testcase Classes or Test Methods.

When to Use It

We should use Test Selection when we wish to run a subset of tests chosen from

other test suites and we do not want to maintain a separate structure built using

Test Enumeration (page 399). A Smoke Test [SCM] suite is a common usage; see

Named Test Suite (page 592) for other uses.

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Testcase

Class

Test

Suite

Object

Exercise

Create

Fixture

SUT

Run

Test Runner

Test

Selection

Mechanism

Get

Add

Subset

Suite

Object

Create

Testcase

Object

testMethod_n

Testcase

Object

testMethod_1

Testcase

Class

Test

Suite

Object

Exercise

Create

Fixture

SUT

Run

Test Runner

Test

Selection

Mechanism

Get

Add

Subset

Suite

Object

Create

Test Selection

Test

Selection

403

Implementation Notes

Test Selection can be implemented either by creating a Subset Suite (see

Named Test Suite) from an existing Test Suite Object (page 387) or by skip-

ping some of the tests within the Test Suite Object as we execute the Testcase

Objects (page 382) it contains.

As with Test Discovery (page 393) and Test Enumeration, Test Selection

can be applied at two different levels: selecting Testcase Classes or selecting

Test Methods. Test Selection can be built into the Test Automation Frame-

work (page 298) or it can be implemented more crudely as part of the build

task.

Variation: Testcase Class Selection

We can select the Testcase Classes to be examined for Test Methods in several

ways. The crudest way to do Testcase Class Selection is simply to place the Test-

case Classes into test packages based on some criteria. Unfortunately, this strategy

works only for a single test classiﬁ cation scheme and is likely to reduce the value

of Tests as Documentation (see page 23). A somewhat more ﬂ exible approach is

to use a naming convention such as “contains ‘WebServer’” to select only those

classes that verify the behavior of certain parts of the system. This, too, is some-

what constrained in its utility.

The most ﬂ exible way to implement Test Selection is within the Test Auto-

mation Framework. We can use class attributes (.NET) or annotations (Java) to

indicate characteristics of the Testcase Class. The same technique can also be

applied at the Test Method level.

Variation: Test Method Selection

When implemented as part of the Test Automation Framework, Test Method

Selection can be done by specifying the “category” (or categories) to which a Test

Method belongs. This usually requires language support for method attributes

(.NET) or annotations (Java). It could also be based on a method name scheme,

although this approach is not as ﬂ exible and would require tighter coupling to

the Test Runner.

Example: Testcase Class Selection Using Class Attributes

The following example of Testcase Class Selection is from NUnit. The class

attribute Category(“FastSuite”) indicates that all tests in this Testcase Class

should be included (or excluded) when the category “FastSuite” is speciﬁ ed

in the Test Runner.

404

Chapter 19 xUnit Basics Patterns

Test

Selection

405

[TestFixture]

[Category("FastSuite")]

public class CategorizedTests

{

[Test]

public void testFlightConstructor_OK()

// Methods omitted

}

Example: Test Method Selection Using Method Attributes

This example of Test Method Selection is from NUnit. The method attribute

Category(“SmokeTest”) indicates that this Test Method should be included (or

excluded) when the category “SmokeTest” is speciﬁ ed in the Test Runner.

[Test]

[Category("SmokeTests")]

public void testFlightMileage_asKm()

{

// set up ﬁxture

Flight newFlight = new Flight(validFlightNumber);

newFlight.setMileage(1122);

// exercise mileage translator

int actualKilometres = newFlight.getMileageAsKm();

int expectedKilometres = 1810;

// verify results

Assert.AreEqual( expectedKilometres, actualKilometres);

}

Test

Selection

Test Selection

This page intentionally left blank

Chapter 20

Fixture Setup Patterns

Patterns in This Chapter

Fresh Fixture Setup

In-line Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

Delegated Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Creation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Implicit Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Shared Fixture Construction

Prebuilt Fixture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

Lazy Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Suite Fixture Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Setup Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Chained Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

Fixture Setup

Patterns

407