Meszaros G. xUnit Test Patterns Refactoring Test Code

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

to other systems.

We put all business logic into a Service Layer [PEAA] that

exposes the application functionality to the presentation layer as an API. We

treat each layer of the architecture as a separate SUT. We write component tests

for each layer independent of the other layers of the architecture. That is, for

layer n of the architecture, the tests will take the place of layer n+1; we may op-

tionally replace layer n-1 with a Test Double (page 522).

When to Use It

We can use a Layer Test whenever we have a layered architecture and we want

to provide good test coverage of the logic in each layer. It can be much simpler

to test each layer independently than it is to test all the layers at once. This is

especially true when we want to do defensive coding for return values of calls

across the layer boundary. In software that is working correctly, these errors

“should never happen”; in real life, they do. To make sure our code handles

these errors, we can inject these “never happen” scenarios as indirect inputs

to our layer.

Layer Tests are very useful when we want to divide up the project team into

subteams based on the technology in which the team members specialize. Each

layer of an architecture tends to require different knowledge and often uses

different technologies; therefore, the layer boundaries serve as natural team

boundaries. Layer Tests can be a good way to nail down and document the

semantics of the layer interfaces.

Even when we choose to use a Layer Test strategy, it is a good idea to include

a few “top-to-bottom” tests just to verify that the various layers are integrated

correctly. These tests need to cover only one or two basic scenarios; we don’t

need to test every business test condition because all of them have already been

tested in the Layer Tests for at least one of the layers.

Most of the variations on this pattern reﬂ ect which layer is being tested inde-

pendently of the other layers.

Variation: Presentation Layer Test

One could write a whole book just on patterns of presentation layer testing. The

speciﬁ c patterns depend on the nature of the presentation layer technology (e.g.,

graphical user interface, traditional Web interface, “smart” Web interface, Web

services). Regardless of the technology, the key is to test the presentation logic

separately from the business logic so that we don’t have to worry about changes

Not all presentation logic relates to the user interface; this logic can also appear in a

messaging interface used by another application.

Layer Test

Chapter 18 Test Strategy Patterns

338

in the underlying logic affecting our presentation layer tests. (They are hard

enough to automate well as it is!)

Another consideration is to design the presentation layer so that its logic can

be tested independently of the presentation framework. Humble Dialog (see

Humble Object on page 695) is the key design-for-testability pattern to apply

here. In effect, we are deﬁ ning sublayers within the presentation layer; the layer

containing the Humble Dialogs is the “presentation graphic layer” and the layer

we have made testable is the “presentation behavior layer.” This separation of

layers allows us to verify that buttons are activated, menu items are grayed out,

and so on, without instantiating any of the real graphical objects.

Variation: Service Layer Test

The Service Layer is where most of our unit tests and component tests are

traditionally concentrated. Testing the business logic using customer tests is

a bit more challenging because testing the Service Layer via the presentation

layer often involves Indirect Testing and Sensitive Equality (see Fragile Test on

page 239), either of which can lead to Fragile Tests and High Test Maintenance

Cost (page 265). Testing the Service Layer directly helps avoid these problems.

To avoid Slow Tests (page 253), we usually replace the persistence layer with

a Fake Database (see Fake Object on page 551) and then run the tests. In fact,

most of the impetus behind a layered architecture is to isolate this code from the

other, harder-to-test layers. Alistair Cockburn puts an interesting spin on this

idea in his description of a Hexagonal Architecture at http://alistair.cockburn.us

[WWW].

The Service Layer may come in handy for other uses. It can be used to run the

application in “headless” mode (without a presentation layer attached), such as

when using macros to automate frequently done tasks in Microsoft Excel.

Variation: Persistence Layer Test

The persistence layer also needs to be tested. Round-trip tests will often sufﬁ ce

if the application is the only one that uses the data store. But these tests won’t

catch one kind of programming error: when we accidentally put information

into the wrong columns. As long as the data type of the interchanged columns is

compatible and we make the same error when reading the data, our round-trip

tests will pass! This kind of bug won’t affect the operation of our application but

it might make support more difﬁ cult and it will cause problems in interactions

with other applications.

When other applications also use the data store, it is highly advisable to imple-

ment at least a few layer-crossing tests that verify information is put into the

Layer Test

339

correct columns of tables. We can use Back Door Manipulation (page 327) to

either set up the database contents or to verify the post-test database contents.

Variation: Subcutaneous Test

A Subcutaneous Test is a degenerate form of Layer Test that bypasses the pre-

sentation layer of the system to interact directly with the Service Layer. In most

cases, the Service Layer is not isolated from the layer(s) below; therefore, we

test everything except the presentation. Use of a Subcutaneous Test does not

require as strict a separation of concerns as does a Service Layer Test, which

makes Subcutaneous Test easier to use when we are retroﬁ tting tests onto an

application that wasn’t designed for testability. We should use a Subcutaneous

Test whenever we are writing customer tests for an application and we want

to ensure our tests are robust. A Subcutaneous Test is much less likely to be

broken by changes to the application

because it does not interact with the

application via the presentation layer; as a consequence, a whole category of

changes won’t affect it.

Variation: Component Test

A Component Test is the most general form of Layer Test, in that we can think

of the layers being made up of individual components that act as “micro-layers.”

Component Tests are a good way to specify or document the behavior of indi-

vidual components when we are doing component-based development and some

of the components must be modiﬁ ed or built from scratch.

Implementation Notes

We can write our Layer Tests as either round-trip tests or layer-crossing tests.

Each has advantages. In practice, we typically mix both styles of tests. The

round-trip tests are easier to write (assuming we already have a suitable Fake

Object available to use for layer n-1). We need to use layer-crossing tests, how-

ever, when we are verifying the error-handling logic in layer n.

Round-Trip Tests

A good starting point for Layer Tests is the round-trip test, as it should be

sufﬁ cient for most Simple Success Tests (see Test Method on page 348). These

tests can be written such that they do not care whether we have fully isolated

the layer of interest from the layers below. We can either leave the real com-

ponents in place so that they are exercised indirectly, or we can replace them

Less likely than a test that exercises the logic via the presentation layer, that is.

Layer Test

340

Chapter 18 Test Strategy Patterns

with Fake Objects. The latter option is particularly useful when by a database

or asynchronous mechanisms in the layer below lead to Slow Tests.

Controlling Indirect Inputs

We can replace a lower layer of the system with a Test Stub (page 529) that

returns “canned” results based on what the client layer passes in a request (e.g.,

Customer 0001 is a valid customer, 0002 is a dormant customer, 0003 has three

accounts). This technique allows us to test the client logic with well-understood

indirect inputs from the layer below. It is particularly useful when we are auto-

mating Expected Exception Tests (see Test Method) or when we are exercising

behavior that depends on data that arrives from an upstream system.

The

alternative is to use Back Door Manipulation to set up the indirect inputs.

Verifying Indirect Outputs

When we want to verify the indirect outputs of the layer of interest, we can use

a Mock Object (page 544) or Test Spy (page 538) to replace the components in

the layer below the SUT. We can then compare the actual calls made to the DOC

with the expected calls. The alternative is to use Back Door Manipulation to

verify the indirect outputs of the SUT after they have occurred.

Motivating Example

When trying to test all layers of the application at the same time, we must verify

the correctness of the business logic through the presentation layer. The following

test is a very simple example of testing some trivial business logic through a

trivial user interface:

private ﬁnal int LEGAL_CONN_MINS_SAME = 30;

public void testAnalyze_sameAirline_LessThanConnectionLimit()

throws Exception {

// setup

FlightConnection illegalConn =

createSameAirlineConn( LEGAL_CONN_MINS_SAME - 1);

// exercise

FlightConnectionAnalyzerImpl sut =

new FlightConnectionAnalyzerImpl();

String actualHtml =

sut.getFlightConnectionAsHtmlFragment(

illegalConn.getInboundFlightNumber(),

illegalConn.getOutboundFlightNumber());

Typically this data goes directly into a shared database or is injected via a “data

pump.”

Layer Test

341

// veriﬁcation

StringBuffer expected = new StringBuffer();

expected.append("<span class="boldRedText">");

expected.append("Connection time between ﬂight ");

expected.append(illegalConn.getInboundFlightNumber());

expected.append(" and ﬂight ");

expected.append(illegalConn.getOutboundFlightNumber());

expected.append(" is ");

expected.append(illegalConn.getActualConnectionTime());

expected.append(" minutes.</span>");

assertEquals("html", expected.toString(), actualHtml);

}

This test contains knowledge about the business layer functionality (what makes

a connection illegal) and presentation layer functionality (how an illegal connec-

tion is presented). It also depends on the database because the FlightConnections

are retrieved from another component. If any of these areas change, this test

must be revisited as well.

Refactoring Notes

We can split this test into two separate tests: one to test the business logic

(What constitutes an illegal connection?) and one to test the presentation

layer (Given an illegal connection, how should it be displayed to the user?).

We would typically do so by duplicating the entire Testcase Class (page 373),

stripping out the presentation layer logic veriﬁ cation from the business layer

Test Methods, and stubbing out the business layer object(s) in the presentation

layer Test Methods.

Along the way, we will probably ﬁ nd that we can reduce the number of tests

in at least one of the Testcase Classes because few test conditions exist for that

layer. In this example, we started out with four tests (the combinations of same/

different airlines and time periods), each of which tested both the business and

presentation layers; we ended up with four tests in the business layer (the origi-

nal combinations but tested directly) and two tests in the presentation layer

(formatting of legal and illegal connections).

Therefore, only the latter two

tests need to be concerned with the details of the string formatting and, when a

test fails, we know which layer holds the bug.

We can take our refactoring even further by using a Replace Dependency

with Test Double (page 739) refactoring to turn this Subcutaneous Test into a

true Service Layer Test.

I’m glossing over the various error-handling tests to simplify this discussion, but note

that a Layer Test

also makes it easier to exercise the error-handling logic.

342

Chapter 18 Test Strategy Patterns

Layer Test

343

Example: Presentation Layer Test

The following example shows the earlier test refactored to verify the behavior

of the presentation layer when an illegal connection is requested. It stubs out

the FlightConnAnalyzer and conﬁ gures it with the illegal connection to return to

the HtmlFacade when it is called. This technique gives us complete control over the

indirect input of the SUT.

public void testGetFlightConnAsHtml_illegalConnection()

throws Exception {

// setup

FlightConnection illegalConn = createIllegalConnection();

Mock analyzerStub = mock(IFlightConnAnalyzer.class);

analyzerStub.expects(once()).method("analyze")

.will(returnValue(illegalConn));

HTMLFacade htmlFacade =

new HTMLFacade( (IFlightConnAnalyzer)analyzerStub.proxy());

// exercise

String actualHtmlString =

htmlFacade.getFlightConnectionAsHtmlFragment(

illegalConn.getInboundFlightNumber(),

illegalConn.getOutboundFlightNumber());

// verify

StringBuffer expected = new StringBuffer();

expected.append("<span class="boldRedText">");

expected.append("Connection time between ﬂight ");

expected.append(illegalConn.getInboundFlightNumber());

expected.append(" and ﬂight ");

expected.append(illegalConn.getOutboundFlightNumber());

expected.append(" is ");

expected.append(illegalConn.getActualConnectionTime());

expected.append(" minutes.</span>");

assertEquals("returned HTML",

expected.toString(),

actualHtmlString);

}

We must compare the string representations of the HTML to determine whether

the code has generated the correct response. Fortunately, we need only two such

tests to verify the basic behavior of this component.

Example: Subcutaneous Test

Here’s the original test converted into a Subcutaneous Test that bypasses the

presentation layer to verify that the connection information is calculated cor-

rectly. Note the lack of any string manipulation in this test.

Layer Test

344

Chapter 18 Test Strategy Patterns

private ﬁnal int LEGAL_CONN_MINS_SAME = 30;

public void testAnalyze_sameAirline_LessThanConnectionLimit()

throws Exception {

// setup

FlightConnection expectedConnection =

createSameAirlineConn( LEGAL_CONN_MINS_SAME -1);

// exercise

IFlightConnAnalyzer theConnectionAnalyzer =

new FlightConnAnalyzer();

FlightConnection actualConnection =

theConnectionAnalyzer.getConn(

expectedConnection.getInboundFlightNumber(),

expectedConnection.getOutboundFlightNumber());

// veriﬁcation

assertNotNull("actual connection", actualConnection);

assertFalse("IsLegal", actualConnection.isLegal());

}

While we have bypassed the presentation layer, we have not attempted to isolate

the Service Layer from the layers below. This omission could result in Slow Tests

or Erratic Tests (page 228).

Example: Business Layer Test

The next example shows the same test converted into a Service Layer Test that

is fully isolated from the layers below it. We have used JMock to replace these

components with Mock Objects that verify the correct ﬂ ights are being looked

up and that inject the corresponding ﬂ ight constructed into the SUT.

public void testAnalyze_sameAirline_EqualsConnectionLimit()

throws Exception {

// setup

Mock ﬂightMgntStub = mock(FlightManagementFacade.class);

Flight ﬁrstFlight = createFlight();

Flight secondFlight = createConnectingFlight(

ﬁrstFlight, LEGAL_CONN_MINS_SAME);

ﬂightMgntStub.expects(once()).method("getFlight")

.with(eq(ﬁrstFlight.getFlightNumber()))

.will(returnValue(ﬁrstFlight));

ﬂightMgntStub.expects(once()).method("getFlight")

.with(eq(secondFlight.getFlightNumber()))

.will(returnValue(secondFlight));

// exercise

FlightConnAnalyzer theConnectionAnalyzer = new FlightConnAnalyzer();

theConnectionAnalyzer.facade =

(FlightManagementFacade)ﬂightMgntStub.proxy();

FlightConnection actualConnection =

theConnectionAnalyzer.getConn(

ﬁrstFlight.getFlightNumber(),

secondFlight.getFlightNumber());

Layer Test

345

// veriﬁcation

assertNotNull("actual connection", actualConnection);

assertTrue("IsLegal", actualConnection.isLegal());

}

This test runs very quickly because the Service Layer is fully isolated from any

underlying layers. It is also likely to be much more robust because it tests much

less code.

Layer Test

This page intentionally left blank

347

Chapter 19

xUnit Basics Patterns

Patterns in This Chapter

Test Deﬁ nition

Test Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Four-Phase Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Assertion Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Assertion Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Testcase Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Test Execution

Test Runner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Testcase Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Test Suite Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Test Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Test Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Test Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

xUnit Basics

Patterns