Meszaros G. xUnit Test Patterns Refactoring Test Code

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

168

Chapter 13 Testing with Databases

Why Test with Databases?

Many applications include a database to persist objects or data into longer-term

storage. The database is a necessary part of the application, so verifying that the

database is used properly is a necessary part of building the application. Therefore,

the use of a Database Sandbox (page 650) to isolate developers and testers from

production (and each other) is a fundamental practice on almost every project

(Figure 13.1).

Figure 13.1 A Database Sandbox for each developer. Sharing a Database

Sandbox among developers is false economy. Would you make a plumber and

an electrician work in the same wall at the same time?

Issues with Databases

A database introduces a number of issues that complicate test automation. Many

of these issues relate to the fact that the ﬁ xture is persistent. These issues were

introduced in Chapter 9, Persistent Fixture Management, and are summarized

brieﬂ y here.

Persistent Fixtures

Applications with databases present some special challenges when we are

writing automated tests. Databases are much slower than the processors used

in modern computers. As a consequence, tests that interact with a database

tend to run much more slowly than tests that can run entirely in memory. But

even ignoring the Slow Tests issue, databases are a prime source of test smells

in our automated test suites. Commonly encountered smells include Erratic

SUT

Setup

Exercise

Verify

Teardown

Database

Fixture

Developer 1

Database

SUT

Setup

Exercise

Verify

Teardown

Fixture

Developer 2

SUT

Setup

Exercise

Verify

Teardown

Database

Fixture

Developer 1

Database

SUT

Setup

Exercise

Verify

Teardown

Fixture

Developer 2

169

Tests (page 228) and Obscure Tests (page 186). Because the data in a database

may potentially persist long after we run our test, we must pay special atten-

tion to this data to avoid creating tests that can be run only once or tests that

interact with one another. These Unrepeatable Tests (see Erratic Test) and

Interacting Tests (see Erratic Test) are a direct consequence of the persistence

of the test ﬁ xture and can result in more expensive maintenance of our tests as

the application evolves.

Shared Fixtures

Persistence of the ﬁ xture is one thing; choosing to share it is another. Deliberate

sharing of the ﬁ xture can result in Lonely Tests (see Erratic Test) if some tests

depend on other tests to set up the ﬁ xture for them—a situation called Chained

Tests (page 454). If we haven’t provided each developer with his or her own

Database Sandbox, we might spark a Test Run War (see Erratic Test) between

developers. This problem arises when the tests being run from two or more Test

Runners (page 377) interact by virtue of their accessing the same ﬁ xture objects

in the shared database instance. Each of these behavior smells is a direct conse-

quence of the decision to share the test ﬁ xture. The degree of persistence and the

scope of ﬁ xture sharing directly affect the presence or absence of these smells.

General Fixtures

Another problem with tests that rely on databases is that databases tend to evolve

into a large General Fixture (see Obscure Test) that many tests use for different pur-

poses. This outcome is particularly likely when we use a Prebuilt Fixture (page 429)

to avoid setting up the ﬁ xture in each test. It can also result from the decision to use

a Standard Fixture (page 305) when we employ a Fresh Fixture (page 311) strategy.

This approach makes it difﬁ cult to determine exactly what each test is specifying.

In effect, the database appears as a Mystery Guest (see Obscure Test) in all of the

tests.

Testing without Databases

Modern layered software architecture [DDD, PEAA, WWW] opens up the pos-

sibility of testing the business logic without using the database at all. We can

test the business logic layer in isolation from the other layers of the system by

using Layer Tests (page 337) and replacing the data access layer with a Test

Double (page 522); see Figure 13.2.

Testing without Databases

170

Chapter 13 Testing with Databases

Figure 13.2 A pair of Layer Tests, each of which tests a different layer of the

system. Layer Tests allow us to build each layer independently of the other

layers. They are especially useful when the persistence layer can be replaced

by a Test Double that reduces the Context Sensitivity (see Fragile Test on

page 239) of the tests.

If our architecture is not sufﬁ ciently layered to allow for Layer Tests, we may still

be able to test without a real database by using either a Fake Database (see Fake

Object on page 551) or an In-Memory Database (see Fake Object). An In-Memory

Database is a database but stores its tables in memory; this structure makes it run

much faster than a disk-based database. A Fake Database isn’t really a database at

all; it is a data access layer that merely pretends to be one. As a rule, it is easier to

ensure independence of tests by using a Fake Database because we typically cre-

ate a new one as part of our ﬁ xture setup logic, thereby implementing a Transient

Fresh Fixture (see Fresh Fixture) strategy. Nevertheless, both of these strategies

allow our tests to run at in-memory speeds, thereby avoiding Slow Tests. We don’t

introduce too much knowledge of the SUT’s structure as long as we continue to

write our tests as round-trip tests.

Replacing the database with a Test Double works well as long as we use the

database only as a data repository. Things get more interesting if we use any

vendor-speciﬁ c functionality, such as sequence number generation or stored pro-

cedures. Replacing the database then becomes a bit more challenging because it

requires more attention to creating a design for testability. The general strategy

is to encapsulate all database interaction within the data access layer. Where the

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

171

data access layer provides data access functionality, we can simply delegate these

duties to the “database object.” We must provide test-speciﬁ c implementations

for any parts of the data access layer interface that implement the vendor-speciﬁ c

functionality—a task for which a Test Stub (page 529) ﬁ ts the bill nicely.

If we are taking advantage of vendor-speciﬁ c database features such as sequence

number generation, we will need to provide this functionality when executing the

tests in memory. Typically, we will not need to substitute a Test Double for any

functionality-related object because the functionality happens behind the scenes

within the database. We can add this functionality into the in-memory version of

the application using a Strategy [GOF] object, which by default is initialized to

a null object [PLOPD3]. When run in production, the null object does nothing;

when run in memory, the strategy object provides the missing functionality. As

an added beneﬁ t, we will ﬁ nd it easier to change to a different database vendor

once we have taken this step because the hooks to provide this functionality al-

ready exist.

Replacing the database (or the data access layer) via an automated test implies

that we have a way to instruct the SUT to use the replacement object. This is com-

monly done in one of two ways: through direct Dependency Injection (page 678)

or by ensuring that the business logic layer uses Dependency Lookup (page 686)

to ﬁ nd the data access layer.

Testing the Database

Assuming we have found ways to test most of our software without using a

database, then what? Does the need to test the database disappear? Of course not!

We should ensure that the database functions correctly, just like any other soft-

ware we write. We can, however, focus our testing of the database logic so as to

reduce the number and kinds of tests we need to write. Because tests that involve

the database will run much more slowly than our in-memory tests, we want to

keep the number of these tests to the bare minimum.

What kinds of database tests will we require? The answer to this question

depends on how our application uses the database. If we have stored proce-

dures, we should write unit tests to verify their logic. If a data access layer hides

the database from the business logic, we should write tests for the data access

functionality.

Just one more example of how design for testability improves the design of our

applications.

Testing the Database

172

Chapter 13 Testing with Databases

Testing Stored Procedures

We can write tests for stored procedures in one of two ways. A Remote Stored

Procedure Test (see Stored Procedure Test on page 654) is written in the same

programming language and framework as we write all of our other unit tests. It

accesses the stored procedure via the same invocation mechanism as used within

the application logic (i.e., by some sort of Remote Proxy [GOF], Facade [GOF],

or Command object [GOF]). Alternatively, we can write In-Database Stored

Procedure Tests (see Stored Procedure Test) in the same language as the stored

procedure itself; these tests will run inside the database (Figure 13.3). xUnit fam-

ily members are available for several of the most common stored procedure

languages; utPLSQL is just one example.

Figure 13.3 Testing a stored procedure using Self-Checking Tests (see page 26).

There is great value in having automated regression test for stored procedures,

but we must take care to make them repeatable and robust.

Testing the Data Access Layer

We also want to write some unit tests for the data access layer. For the most part,

these data access layer tests can be round-trip tests. Nevertheless, it is useful to

have a few layer-crossing tests to ensure that we are putting information into

the correct columns. This can be done using xUnit framework extensions for

Application Environment

Database

Stored

Procedure

Proxy

Stored

Procedure

Testcase Class

testMethod_1

testMethod_2

Testcase Class

testMethod_1

testMethod_2

Application Environment

Database

Stored

Procedure

Proxy

Stored

Procedure

Testcase Class

testMethod_1

testMethod_2

Testcase Class

testMethod_1

testMethod_2

173

database testing (e.g., DbUnit for Java) to insert data directly into the database

(for “Read” tests) or to verify the post-test contents of the database (for “Cre-

ate/Update/Delete” tests).

A useful trick for keeping our ﬁ xture from becoming persistent during data

access layer testing is to use Transaction Rollback Teardown (page 668). To

do so, we rely on the Humble Transaction Controller (see Humble Object on

page 695) DFT pattern when constructing our data access layer. That is, the

code that reads or writes the database should never commit a transaction; this

allows the code to be exercised by a test that rolls back the transaction to pre-

vent any of the changes made by the SUT from being applied.

Another way to tear down any changes made to the database during the

ﬁ xture setup and exercise SUT phases of the test is Table Truncation Tear-

down (page 661). This “brute force” technique for deleting data works only

when each developer has his or her own Database Sandbox and we want to

clear out all the data in one or more tables.

Ensuring Developer Independence

Testing the database means we need to have the real database available for

running these tests. During this testing process, every developer needs to have

his or her own Database Sandbox. Trying to share a single sandbox among several

or all developers is a false economy; the developers will simply end up tripping

over one another and wasting a lot of time.

I have heard many different excuses

for not giving each developer his or her own sandbox, but frankly none of them

holds water. The most legitimate concern relates to the cost of a database license

for each developer—but even this obstacle can be surmounted by choosing

one of the “virtual sandbox” variations. If the database technology supports it,

we can use a DB Schema per TestRunner (see Database Sandbox); otherwise,

we have to use a Database Partitioning Scheme (see Database Sandbox).

Testing with Databases (Again!)

Suppose we have done a good job layering our system and achieved our goal of

running most of our tests without accessing the real database. Now what kinds

of tests should we run against the real database? The answer is simple: “As few

as possible, but no fewer!” In practice, we want to run at least a representative

sample of our customer tests against the database to ensure that the SUT behaves

Can you image asking a team of carpenters to share a single hammer?

Testing with Databases (Again!)

174

the same way with a database as without one. These tests need not access the busi-

ness logic via the user interface unless some particular user interface functionality

depends on the database; Subcutaneous Tests (see Layer Test) should be adequate

in most circumstances.

What’s Next?

In this chapter, we looked at special techniques for testing with databases. This

discussion has merely scratched the surface of the interactions between agile

software development and databases.

Chapter 14, A Roadmap to Effective Test

Automation, summarizes the material we have covered thus far and makes some

suggestions about how a project team should come up to speed on developer test

automation.

For a more complete treatment of the topic, refer to [RDb].

Chapter 13 Testing with Databases

175

Chapter 14

A Roadmap to Effective Test

Automation

About This Chapter

Chapter 13, Testing with Databases, introduced a set of patterns speciﬁ c to testing

applications that have a database. These patterns built on the techniques described

in Chapter 6, Test Automation Strategy; Chapter 9, Persistent Fixture Manage-

ment; and Chapter 11, Using Test Doubles. This was a lot of material to become

familiar with before we could test effectively with and without databases!

This raises an important point: We don’t become experts in test automa-

tion overnight—these skills take time to develop. It also takes time to learn the

various tools and patterns at our disposal. This chapter provides something of

a roadmap for how to learn the patterns and acquire the skills. It introduces

the concept of “test automation maturity,” which is loosely based on the SEI’s

Capability Maturity Model (CMM).

Test Automation Difﬁ culty

Some kinds of tests are harder to write than others. This difﬁ culty arises partly

because the techniques are more involved and partly because they are less well

known and the tools to do this kind of test automation are less readily avail-

able. The following common kinds of tests are listed in approximate order of

difﬁ culty, from easiest to most difﬁ cult:

1. Simple entity objects (Domain Model [PEAA])

• Simple business classes with no dependencies

• Complex business classes with dependencies

176

Chapter 14 A Roadmap to Effective Test Automation

2. Stateless service objects

• Individual components via component tests

• The entire business logic layer via Layer Tests (page 337)

3. Stateful service objects

• Customer tests via a Service Facade [CJ2EEP] using Subcutaneous

Tests (see Layer Test)

• Stateful components via component tests

4. “Hard-to-test” code

• User interface logic exposed via Humble Dialog (see Humble

Object on page 695)

• Database logic

• Multi-threaded software

5. Object-oriented legacy software (software built without any tests)

6. Non-object-oriented legacy software

As we move down this list, the software becomes increasingly more challenging to

test. The irony is that many teams “get their feet wet” by trying to retroﬁ t tests onto

an existing application. This puts them in one of the last two categories in this list,

which is precisely where the most experience is required. Unfortunately, many teams

fail to test the legacy software successfully, which may then prejudice them against

trying automated testing, with or without test-driven development. If you ﬁ nd your-

self trying to learn test automation by retroﬁ tting tests onto legacy software, I have

two pieces of advice for you: First, hire someone who has done it before to help you

through this process. Second, read Michael Feathers’ excellent book [WEwLC]; he

covers many techniques speciﬁ cally applicable to retroﬁ tting tests.

Roadmap to Highly Maintainable Automated Tests

Given that some kinds of tests are much harder to write than others, it makes

sense to focus on learning to write the easier tests ﬁ rst before we move on to the

more difﬁ cult kinds of tests. When teaching automated testing to developers, I

introduce the techniques in the following sequence. This roadmap is based on

Maslow’s hierarchy of needs [HoN], which says that we strive to meet the higher-

level needs only after we have satisﬁ ed the lower-level needs.

177

1. Exercise the happy path code

• Set up a simple pre-test state of the SUT

• Exercise the SUT by calling the method being tested

2. Verify direct outputs of the happy path

• Call Assertion Methods (page 362) on the SUT’s responses

• Call Assertion Methods on the post-test state

3. Verify alternative paths

• Vary the SUT method arguments

• Vary the pre-test state of the SUT

• Control indirect inputs of the SUT via a Test Stub (page 529)

4. Verify indirect output behavior

• Use Mock Objects (page 544) or Test Spies (page 538) to intercept

and verify outgoing method calls

5. Optimize test execution and maintainability

• Make the tests run faster

• Make the tests easy to understand and maintain

• Design the SUT for testability

• Reduce the risk of missed bugs

This ordering of needs isn’t meant to imply that this is the order in which we

might think about implementing any speciﬁ c test.

Rather, it is likely to be the

order in which a project team might reasonably expect to learn about the tech-

niques of test automation.

Let’s look at each of these points in more detail.

Exercise the Happy Path Code

To run the happy path through the SUT, we must automate one Simple Success

Test (see Test Method on page 348) as a simple round-trip test through the SUT’s

API. To get this test to pass, we might simply hard-code some of the logic in the

Although it can also be used that way, I ﬁ nd it better to write the assertions ﬁ rst and

then work back from there.

Roadmap to Highly Maintainable Automated Tests