Meszaros G. xUnit Test Patterns Refactoring Test Code

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

158

Chapter 12 Organizing Our Tests

Choosing a Test Method Organization Strategy

Clearly, there is no single “best practice” we can always follow; the best prac-

tice is the one that is most appropriate for the particular circumstance. Testcase

Class per Fixture is commonly used when we are writing unit tests for stateful

objects and each method needs to be tested in each state of the object. Testcase

Class per Feature (page 624) is more appropriate when we are writing customer

tests against a Service Facade [CJ2EEP]; it enables us to keep all the tests for

a customer-recognizable feature together. This pattern is also more commonly

used when we rely on a Prebuilt Fixture (page 429) because ﬁ xture setup logic

is not required in each test. When each test needs a slightly different ﬁ xture, the

right answer may be to select the Testcase Class per Feature pattern and use a

Delegated Setup (page 411) to facilitate setting up the ﬁ xtures.

Test Naming Conventions

The names we give to our Testcase Classes and Test Methods are crucial in mak-

ing our tests easy to ﬁ nd and understand. We can make the test coverage more

obvious by naming each Test Method systematically based on which test condi-

tion it veriﬁ es. Regardless of which test method organization scheme we use, we

would like the combination of the names of the test package, the Testcase Class,

and the Test Method to convey at least the following information:

• The name of the SUT class

• The name of the method or feature being exercised

• The important characteristics of any input values related to the exercising

of the SUT

• Anything relevant about the state of the SUT or its dependencies

These items are the “input” part of the test condition. Obviously, this is a lot

to communicate in just two names but the reward is high if we can achieve it:

We can tell exactly what test conditions we have tests for merely by looking at

the names of the classes and methods in an outline view of our IDE. Figure 12.5

provides an example.

159

Figure 12.5 A production class with one Testcase Class for each test ﬁ xture.

When we use the Testcase Class per Fixture pattern, the class name can describe

the ﬁ xture, leaving the method name available for describing the inputs and

expected outputs.

Figure 12.5 also shows how useful it is to include the “expectations” side of the

test condition:

• The outputs (responses) expected when exercising the SUT

• The expected post-exercise state of the SUT and its dependencies

This information can be included in the name of the Test Method preﬁ xed by

“should.” If this nomenclature makes the names too long,

we can always access

the expected outcome by looking at the body of the Test Method.

Many xUnit variants “encourage” us to start all our Test Method names with “test”

so that these methods can be automatically detected and added to the Test Suite Object.

This constrains our naming somewhat compared to variants that indicate test methods

via method attributes or annotations.

Test Naming Conventions

160

Chapter 12 Organizing Our Tests

Organizing Test Suites

The Testcase Class acts as a Test Suite Factory (see Test Enumeration) when it

returns a Test Suite Object containing a collection of Testcase Objects (page 382),

each representing a Test Method (Figure 12.6). This is the default organization

mechanism provided by xUnit. Most Test Runners allow any class to act as a

Test Suite Factory by implementing a Factory Method [GOF], which is typi-

cally called

suite.

Figure 12.6 A Testcase Class acting as a Test Suite Factory. By default, the

Testcase Class acts as a Test Suite Factory to produce the Test Suite Object that

the Test Runner requires to execute our tests. We can also enumerate a speciﬁ c

set of tests we want to run by providing a Test Suite Factory that returns a Test

Suite Object containing only the desired tests.

Running Groups of Tests

We often want to run groups of tests (i.e., a test suite) but we don’t want this

decision to constrain how we organize them. A popular convention is to create

a special Test Suite Factory called AllTests for each package of tests. We don’t

need to stop there, however: We can create Named Test Suites (page 592) for

any collection of tests we want to run together. A good example is a Subset Suite

(see Named Test Suite) that allows us to run just those tests that need software

Fixture

Testcase Class

Testcase Object

Implicit setUp

Implicit tearDown

Testcase Object

Implicit setUp

Implicit tearDown

SUT

Test

Suite

Object

testMethod_1

testMethod_n

Test

Suite

Factory

Creation

Fixture

Testcase Class

Testcase Object

Implicit setUp

Implicit tearDown

Testcase Object

Implicit setUp

Implicit tearDown

SUT

Test

Suite

Object

testMethod_1

testMethod_n

Test

Suite

Factory

Creation

161

deployed to the Web server (or not deployed to the Web server!). We usually

have at least a Subset Suite for all the unit tests and another Subset Suite for

just the customer tests (they often take a long time to execute). Some variants of

xUnit support Test Selection (page 403), which we can use instead of deﬁ ning

Subset Suites.

Such runtime groupings of tests often reﬂ ect the environment in which they

need to run. For example, we might have one Subset Suite that includes all tests

that can be run without the database and another Subset Suite that includes

all tests that depend on the database. Likewise, we might have separate Subset

Suites for tests that do, and do not, rely on the Web server. If our test package

includes these various kinds of test suites, we can deﬁ ne AllTests as a Suite of

Suites (see Test Suite Object) composed of these Subset Suites. Then any test

that is added to one of the Subset Suites will also be run in AllTests without

incurring extra test maintenance effort.

Running a Single Test

Suppose a Test Method fails in our Testcase Class. We decide to put a break-

point on a particular method—but that method is called in every test. Our

ﬁ rst reaction might be to just muddle through by clicking “Go” each time

the breakpoint is hit until we are being called from the test of interest. One

possibility is to disable (by commenting out) the other Test Methods so they

are not run. Another option is to rename the other Test Methods so that the

xUnit Test Discovery mechanism will not recognize them as tests. In variants

of xUnit that use method attributes or annotations, we can add the “Ignore”

attribute to a test method instead. Each of these approaches introduces the

potential problem of a Lost Test (see Production Bugs on page 268), although

the “Ignore” approach does remind us that some tests are being ignored. In

members of the xUnit family that provide a Test Tree Explorer (see Test Run-

ner), we can simply select a single test to be run from the hierarchy view of the

test suite, as shown in Figure 12.7.

When none of these options is available, we can use a Test Suite Factory to

run a single test. Wait a minute! Aren’t test suites all about running groups of

tests that live in different Testcase Classes? Well, yes, but that doesn’t mean

we can’t use them for other purposes. We can deﬁ ne a Single Test Suite

(see

Named Test Suite) that runs a particular test. To do so, we call the constructor

of the Testcase Class with the speciﬁ c Test Method’s name as an argument.

I usually call it MyTest.

Organizing Test Suites

162

Chapter 12 Organizing Our Tests

Figure 12.7 A Test Tree Explorer showing the structure of the tests in our suite.

We can use the Test Tree Explorer to drill down into the runtime structure of the

test suite and run individual tests or subsuites.

Test Code Reuse

Test Code Duplication (page 213) can signiﬁ cantly increase the cost of writing

and maintaining tests. Luckily, a number of techniques for reusing test logic

are available to us. The most important consideration is that any reuse not

compromise the value of the Tests as Documentation (see page 23). I don’t

recommend reuse of the actual Test Method in different circumstances (e.g.,

with different ﬁ xtures), as this kind of reuse is typically a sign of a Flexible

Test (see Conditional Test Logic on page 200) that tests different things in dif-

ferent circumstances. Most test code reuse is achieved either through Implicit

Setup or Test Utility Methods (page 599). The major exception is the reuse

of Test Doubles (page 522) by many tests; we can treat these Test Double

classes as a special kind of Test Helper (page 643) when thinking about where

to put them.

163

Test Utility Method Locations

Figure 12.8 The various places we can put Test Utility Methods. The primary

decision-making criterion is the desired scope of reusability of the Test Methods.

Many variants of xUnit provide a special Testcase Superclass (page 638)—typically

called “TestCase”—from which all Testcase Classes should (and, in some cases,

must) inherit either directly or indirectly (Figure 12.8). If we have useful utility

methods on our Testcase Class that we want to reuse in other Testcase Classes,

we may ﬁ nd it helpful to create one or more Testcase Superclasses from which to

inherit instead of “TestCase.” If we take this step, we need to be careful if those

methods need to see types or classes that reside in various packages within the

SUT—our root Testcase Superclass should not depend on those types or classes

directly, as that is likely to result in a cyclical dependency graph. We may be able

to create a Testcase Superclass for each test package to keep our test class de-

pendencies noncyclic. The alternative is to create a Test Helper for each domain

package and put the various Test Helpers in the appropriate test packages. This

way, a Testcase Class is not forced to choose a single Testcase Superclass; it can

merely “use” the appropriate Test Helpers.

TestCase Inheritance and Reuse

The most commonly used reason for inheriting methods from a Testcase Super-

class is to access Test Utility Methods. Another use is when testing frameworks

Fixture

SUT

Test Helper

Test Utility

Method

Testcase

Class

testMethod_1

testMethod_n

Test Utility

Method

Testcase

Superclass

Test Utility

Method

Fixture

SUT

Test Helper

Test Utility

Method

Testcase

Class

testMethod_1

testMethod_n

Test Utility

Method

Testcase

Superclass

Test Utility

Method

Test Code Reuse

164

Chapter 12 Organizing Our Tests

and their plug-ins; it can be useful to create a conformance test that speciﬁ es the

general behavior of the plug-in via a Template Method [GOF] that calls meth-

ods provided by a subclass speciﬁ c to the kind of plug-in being tested to check

speciﬁ c details of the plug-in. This scenario is rare enough that I won’t describe

it further here; please refer to [FaT] for a more complete description.

Test File Organization

Now we face a new question: Where should we put our Testcase Classes?

Obviously, these classes should be stored in the source code repository [SCM]

along with the production code. Beyond that criterion, we have quite a range

of choices. The test packaging strategy we choose will very much depend on

our environment—many IDEs include constraints that make certain strate-

gies unworkable. The key issue is to Keep Test Logic Out of Production Code

(see page 45) and yet to be able to ﬁ nd the corresponding test for each piece of

code or functionality.

Built-in Self-Test

With a built-in self-test, the tests are included with the production code and can

be run at any time. No provision is made for keeping them separate. Many orga-

nizations want to Keep Test Logic Out of Production Code so built-in self-tests

may not be a good option for them. This consideration is particularly important

in memory-constrained environments where we don’t want test code taking up

valuable space.

Some development environments encourage us to keep the tests and the pro-

duction code together. For example, SAP’s ABAP Unit supports the keyword

“For Testing,” which tells the system to disable the tests when the code is trans-

ported into the production environment.

Test Packages

If we decide to put the Testcase Classes into separate test packages, we can

organize them in several ways. We can keep the tests separate by putting them

into one or more test packages while keeping them in the same source tree, or

we can put the tests into the same logical package but physically store them in

a parallel source tree. The latter approach is frequently used in Java because it

avoids the problem of tests not being able to see “package-protected” methods

165

on the SUT.

Some IDEs may reject using this approach by insisting that a pack-

age be wholly contained within a single folder or project. When we use test

packages under each production code package, we may need to use a build-time

test stripper to exclude them from production builds.

Test Dependencies

However we decide to store and manage the source code, we need to ensure that

we eliminate any Test Dependency in Production (see Test Logic in Production

on page 217) because even a test stripper cannot remove the tests if production

code needs them to be present to run. This requirement makes paying attention to

our class dependencies important. We also don’t want to have any Test Logic in

Production because it means we aren’t testing the same code that we will eventu-

ally run in production. This issue is discussed in more detail in Chapter 6, Test

Automation Strategy.

What’s Next?

Now that we’ve looked at how to organize our test code, we should become

familiar with a few more testing patterns. These patterns are introduced in

Chapter 13, Testing with Databases.

Java offers another way to get around the visibility issue: We can deﬁ ne our own test

Security Manager to allow tests to access all methods on the SUT, not just the “package-

protected” ones. This approach solves the problem in a general way but requires a

good understanding of Java class loaders. Other languages may not have the equivalent

functionality (or problem!).

What’s Next?

This page intentionally left blank

167

Chapter 13

Testing with Databases

About This Chapter

In Chapter 12, Organizing Our Tests, we looked at techniques for organizing

our test code. In this chapter, we explore the issues that arise when our appli-

cation includes a database. Applications with databases present some special

challenges when writing automated tests. Databases are much slower than

the processors used in modern computers. As a result, tests that interact with

databases tend to run much, much more slowly than tests that can run entirely

in memory.

Even ignoring the potential for Slow Tests (page 253), databases are a ripe

source for many test smells in our automated test suites. Some of these smells are

a direct consequence of the persistent nature of the database, while others result

from our choice to share the ﬁ xture instance between tests. These smells were

introduced in Chapter 9, Persistent Fixture Management. This chapter expands

on them and provides a more focused treatment of testing with databases.

Testing with Databases

Here is my ﬁ rst, and most critical, piece of advice on this subject:

When there is any way to test without a database, test without the

database!

This seems like pretty strong advice but it is phrased this way for a reason. Data-

bases introduce all sorts of complications into our applications and especially into

our tests. Tests that require a database run, on average, two orders of magnitude

slower than the same tests that run without a database.