Meszaros G. xUnit Test Patterns Refactoring Test Code

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

188

Chapter 15 Code Smells

assertEquals( expectedKilometres, actualKilometres);

// now try it with a canceled ﬂight

newFlight.cancel();

try {

newFlight.getMileageAsKm();

fail("Expected exception");

} catch (InvalidRequestException e) {

assertEquals( "Cannot get cancelled ﬂight mileage",

e.getMessage());

}

Root Cause

When executing tests manually, it makes sense to chain a number of logically

distinct test conditions into a single test case to reduce the setup overhead of

each test. This works because we have liveware (an intelligent human being)

executing the tests, and this person can decide at any point whether it makes

sense to keep going or whether the failure of a step is severe enough to abandon

the execution of the test.

Possible Solution

When the tests are automated, it is better to have a suite of independent Single-

Condition Tests (see page 45) as these provide much better Defect Localization

(see page 22).

Cause: Mystery Guest

The test reader is not able to see the cause and effect between ﬁ xture and veriﬁ -

cation logic because part of it is done outside the Test Method.

Symptoms

Tests invariably require passing data to the SUT. The data used in the ﬁ xture

setup and exercise SUT phases of the Four-Phase Test (page 358) deﬁ ne the pre-

conditions of the SUT and inﬂ uence how it should behave. The post-conditions

(the expected outcomes) are reﬂ ected in the data passed as arguments to the

Assertion Methods (page 362) in the verify outcome phase of the test.

When either the ﬁ xture setup or the result veriﬁ cation part of a test depends

on information that is not visible within the test and the test reader ﬁ nds it dif-

ﬁ cult to understand the behavior that is being veriﬁ ed without ﬁ rst ﬁ nding and

inspecting the external information, we have a Mystery Guest on our hands.

Here’s an example where we cannot tell what the ﬁ xture looks like, making it

difﬁ cult to relate the expected outcome to the pre-conditions of the test:

Obscure

Test

189

public void testGetFlightsByFromAirport_OneOutboundFlight_mg()

throws Exception {

loadAirportsAndFlightsFromFile("test-ﬂights.csv");

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirportCode( "YYC");

// Verify Outcome

assertEquals( 1, ﬂightsAtOrigin.size());

FlightDto ﬁrstFlight = (FlightDto) ﬂightsAtOrigin.get(0);

assertEquals( "Calgary", ﬁrstFlight.getOriginCity());

}

Impact

The Mystery Guest makes it hard to see the cause–effect relationship between

the test ﬁ xture (the pre-conditions of the test) and the expected outcome of

the test. As a consequence, the tests don’t fulﬁ ll the role of Tests as Docu-

mentation. Even worse, someone may modify or delete the external resource

without realizing the impact this action will have when the tests are run. This

behavior smell has its own name: Resource Optimism (see Erratic Test on

page 228)!

If the Mystery Guest is a Shared Fixture (page 317), it may also lead to Erratic

Tests if other tests modify it.

Root Cause

A test depends on mysterious external resources, making it difﬁ cult to under-

stand the behavior that it is verifying. Mystery Guests may take many forms:

•A ﬁ lename of an existing external ﬁ le is passed to a method of the SUT;

the contents of the ﬁ le should determine the behavior of the SUT.

• The contents of a database record identiﬁ ed by a literal key are read

into an object that is then used by the test or passed to the SUT.

• The contents of a ﬁ le are read and used in calls to Assertion Methods to

verify the expected outcome.

•ASetup Decorator (page 447) is used to create a Shared Fixture, and

objects in this ﬁ xture are then referenced via variables within the result

veriﬁ cation logic.

•AGeneral Fixture is set up using Implicit Setup (page 424), and the Test

Methods then access them via instance variables or class variables.

All of these scenarios share a common outcome: It is hard to see the cause–effect

relationship between the test ﬁ xture and the expected outcome of the test because

Obscure Test

Obscure

Test

190

Chapter 15 Code Smells

the relevant data are not visible in the tests. If the contents of the data are not

clearly described by the names we give to the variables and ﬁ les that contain

them, we have a Mystery Guest.

Possible Solution

Using a Fresh Fixture (page 311) built using In-line Setup (page 408) is the

obvious solution for a Mystery Guest. When applied to the ﬁ le example, this

would involve creating the contents of the ﬁ le as a string within our test so

that the contents are visible and then writing them out to the ﬁ le system

[Setup External Resource (page 772) refactoring] or putting it into a ﬁ le sys-

tem Test Stub (page 529) as part of the ﬁ xture setup.

To avoid Irrelevant

Information, we may want to hide the details of the construction behind one

or more evocatively named Creation Methods (page 415) that append to the

ﬁ le’s contents.

If we must use a Shared Fixture or Implicit Setup, we should consider using

evocatively named Finder Methods (see Test Utility Method on page 599) to

access the objects in the ﬁ xture. If we must use external resources such as ﬁ les,

we should put them into a special folder or directory and give them names that

make it obvious what kind of data they hold.

Cause: General Fixture

The test builds or references a larger ﬁ xture than is needed to verify the func-

tionality in question.

Symptoms

There seems to be a lot of test ﬁ xture being built—much more than would appear

to be necessary for any particular test. It is hard to understand the cause–effect

relationship between the ﬁ xture, the part of the SUT being exercised, and the

expected outcome of a test.

Consider the following set of tests:

public void testGetFlightsByFromAirport_OneOutboundFlight()

throws Exception {

setupStandardAirportsAndFlights();

FlightDto outboundFlight = ﬁndOneOutboundFlight();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlight.getOriginAirportId());

// Verify Outcome

See In-line Resource (page 736) refactoring for details.

Obscure

Test

191

assertOnly1FlightInDtoList( "Flights at origin",

outboundFlight,

ﬂightsAtOrigin);

}

public void testGetFlightsByFromAirport_TwoOutboundFlights()

throws Exception {

setupStandardAirportsAndFlights();

FlightDto[] outboundFlights =

ﬁndTwoOutboundFlightsFromOneAirport();

// Exercise System

List ﬂightsAtOrigin = facade.getFlightsByOriginAirport(

outboundFlights[0].getOriginAirportId());

// Verify Outcome

assertExactly2FlightsInDtoList( "Flights at origin",

outboundFlights,

ﬂightsAtOrigin);

}

From reading the exercise SUT and veriﬁ ng outcome parts of the tests, it would

appear that they need very different ﬁ xtures. Even though these tests are using a

Fresh Fixture setup strategy, they are using the same ﬁ xture setup logic by calling

the setupStandardAirportsAndFlights method. The name of the method is a clue to

this classic but easily recognized example of a General Fixture. A more difﬁ cult

case to diagnose would be if each test created the Standard Fixture (page 305)

in-line or if each test created a somewhat different ﬁ xture but each ﬁ xture con-

tained much more than was needed by each individual test.

We may also be experiencing Slow Tests (page 253) or a Fragile Fixture (see

Fragile Test on page 239).

Root Cause

The most common cause of this problem is a test that uses a ﬁ xture that is designed

to support many tests. Examples include the use of Implicit Setup or a Shared Fix-

ture across many tests with different ﬁ xture requirements. This problem results in

the ﬁ xture becoming large and difﬁ cult to understand. The ﬁ xture may also grow

larger over time. The root cause is that both approaches rely on a Standard Fix-

ture that must meet the requirements of all tests that use it. The more diverse the

needs of those tests, the more likely we are to create a General Fixture.

Impact

When the test ﬁ xture is designed to support many different tests, it can be very

difﬁ cult to understand how each test uses the ﬁ xture. This complexity reduces the

likelihood of using Tests as Documentation and can result in a Fragile Fixture as

people alter the ﬁ xture so that it can handle new tests. It can also result in Slow

Obscure Test

Obscure

Test

192

Chapter 15 Code Smells

Tests because a larger ﬁ xture takes more time to build, especially if a ﬁ le system

or database is involved.

Possible Solution

We need to move to a Minimal Fixture (page 302) to address this problem. To

do so, we can use a Fresh Fixture for each test. If we must use a Shared Fixture,

we should consider applying the Make Resource Unique (page 737) refactoring

to create a virtual Database Sandbox (page 650) for each test.

Cause: Irrelevant Information

The test exposes a lot of irrelevant details about the ﬁ xture that distract the test

reader from what really affects the behavior of the SUT.

Symptoms

As test readers, we ﬁ nd it hard to determine which of the values passed to

objects actually affect the expected outcome:

public void testAddItemQuantity_severalQuantity_v10(){

// Set Up Fixture

Address billingAddress =

createAddress( "1222 1st St SW", "Calgary", "Alberta",

"T2N 2V2", "Canada");

Address shippingAddress =

createAddress( "1333 1st St SW", "Calgary", "Alberta",

"T2N 2V2", "Canada");

Customer customer =

createCustomer( 99, "John", "Doe", new BigDecimal("30"),

billingAddress, shippingAddress);

Product product =

createProduct( 88,"SomeWidget",new BigDecimal("19.99"));

Invoice invoice = createInvoice(customer);

// Exercise SUT

invoice.addItemQuantity(product, 5);

// Verify Outcome

LineItem expected =

new LineItem(invoice, product,5, new BigDecimal("30"),

new BigDecimal("69.96"));

assertContainsExactlyOneLineItem(invoice, expected);

}

Switching to an Immutable Shared Fixture (see Shared Fixture) does not fully address

the core of this problem because it does not help us determine which parts of the ﬁ xture

are needed by each test; only the parts that are modiﬁ ed are so identiﬁ ed!

Obscure

Test

193

Fixture setup logic may seem very long and complicated as it weaves together

many interrelated objects. This makes it hard to determine what the test is veri-

fying because the reader doesn’t understand the pre-conditions of the test:

public void testGetFlightsByOriginAirport_TwoOutboundFlights()

throws Exception {

FlightDto expectedCalgaryToSanFran = new FlightDto();

expectedCalgaryToSanFran.setOriginAirportId(calgaryAirportId);

expectedCalgaryToSanFran.setOriginCity(CALGARY_CITY);

expectedCalgaryToSanFran.setDestinationAirportId(sanFranAirportId);

expectedCalgaryToSanFran.setDestinationCity(SAN_FRAN_CITY);

expectedCalgaryToSanFran.setFlightNumber(

facade.createFlight(calgaryAirportId,sanFranAirportId));

FlightDto expectedCalgaryToVan = new FlightDto();

expectedCalgaryToVan.setOriginAirportId(calgaryAirportId);

expectedCalgaryToVan.setOriginCity(CALGARY_CITY);

expectedCalgaryToVan.

setDestinationAirportId(vancouverAirportId);

expectedCalgaryToVan.setDestinationCity(VANCOUVER_CITY);

expectedCalgaryToVan.setFlightNumber(facade.createFlight(

calgaryAirportId, vancouverAirportId));

The code that veriﬁ es the expected outcome of a test can also be too complicated

to understand:

List lineItems = inv.getLineItems();

assertEquals("number of items", lineItems.size(), 2);

// verify ﬁrst item

LineItem actual = (LineItem)lineItems.get(0);

assertEquals(expItem1.getInv(), actual.getInv());

assertEquals(expItem1.getProd(), actual.getProd());

assertEquals(expItem1.getQuantity(), actual.getQuantity());

// verify second item

actual = (LineItem)lineItems.get(1);

assertEquals(expItem2.getInv(), actual.getInv());

assertEquals(expItem2.getProd(), actual.getProd());

assertEquals(expItem2.getQuantity(), actual.getQuantity());

}

Root Cause

A test contains a lot of data, either as Literal Values (page 714) or as variables.

Irrelevant Information often occurs in conjunction with Hard-Coded Test Data

or a General Fixture but can also arise because we make visible all data the

test needs to execute rather than focusing on the data the test needs to be un-

derstood. When writing tests, the path of least resistance is to use whatever

methods are available (on the SUT and other objects) and to ﬁ ll in all parameters

with values, whether or not they are relevant to the test.

Obscure Test

Obscure

Test

194

Chapter 15 Code Smells

Another possible cause is when we include all the code needed to verify

the outcome using Procedural State Veriﬁ cation (see State Veriﬁ cation on

page 462) rather than using a much more compact “declarative” style to spec-

ify the expected outcome.

Impact

It is hard to achieve Tests as Documentation if the tests contain many seemingly

random bits of Obscure Test that don’t clearly link the pre-conditions with the

post-conditions. Likewise, wading through many steps of ﬁ xture setup or result

veriﬁ cation logic can result in High Test Maintenance Cost and can increase the

likelihood of Production Bugs (page 268) or Buggy Tests.

Possible Solution

The best way to get rid of Irrelevant Information in ﬁ xture setup logic is to

replace direct calls to the constructor or Factory Methods [GOF] with calls to

Parameterized Creation Methods (see Creation Method) that take only the rel-

evant information as parameters. Fixture values that do not matter to the test

(i.e., those that do not affect the expected outcome) should be defaulted within

Creation Methods or replaced by Dummy Objects (page 728). In this way we

say to the test reader, “The values you don’t see don’t affect the expected out-

come.” We can replace ﬁ xture values that appear in both the ﬁ xture setup and

outcome veriﬁ cation parts of the test with suitably initialized named constants

as long as we are using a Fresh Fixture approach to ﬁ xture setup.

To hide Irrelevant Information in result veriﬁ cation logic, we can use asser-

tions on entire Expected Objects (see State Veriﬁ cation), rather than asserting

on individual ﬁ elds, and we can create Custom Assertions (page 474) that hide

complex procedural veriﬁ cation logic.

Cause: Hard-Coded Test Data

Data values in the ﬁ xture, assertions, or arguments of the SUT are hard-coded

in the Test Method, obscuring cause–effect relationships between inputs and

expected outputs.

Symptoms

As test readers, we ﬁ nd it difﬁ cult to determine how various hard-coded (i.e.,

literal) values in the test are related to one another and which values should

affect the behavior of the SUT. We may also encounter behavior smells such as

Erratic Tests.

Obscure

Test

195

public void testAddItemQuantity_severalQuantity_v12(){

// Set Up Fixture

Customer cust = createACustomer(new BigDecimal("30"));

Product prod = createAProduct(new BigDecimal("19.99"));

Invoice invoice = createInvoice(cust);

// Exercise SUT

invoice.addItemQuantity(prod, 5);

// Verify Outcome

LineItem expected = new LineItem(invoice, prod, 5,

new BigDecimal("30"), new BigDecimal("69.96"));

assertContainsExactlyOneLineItem(invoice, expected);

}

This speciﬁ c example isn’t so bad because there aren’t very many literal values. If

we aren’t good at doing math in our heads, however, we might miss the relation-

ship between the unit price ($19.99), the item quantity (5), the discount (30%),

and the total price ($69.96).

Root Cause

Hard-Coded Test Data occurs when a test contains a lot of seemingly unrelated

Literal Values. Tests invariably require passing data to the SUT. The data used in

the ﬁ xture setup and exercise SUT phases of the Four-Phase Test deﬁ ne the pre-

conditions of the SUT and inﬂ uence how it should behave. The post-conditions

(the expected outcomes) are reﬂ ected in the data passed as arguments to the

Assertion Methods in the verify outcome phase of the test. When writing tests,

the path of least resistance is to use whatever methods are available (on the SUT

and other objects) and to ﬁ ll in all parameters with values, whether or not they

are relevant to the test.

When we use “cut-and-paste” reuse of test logic, we ﬁ nd ourselves replicat-

ing the literal values to the derivative tests.

Impact

It is hard to achieve Tests as Documentation if the tests contain many seemingly

random bits of Obscure Test that don’t clearly link the pre-conditions with the

post-conditions. A few literal parameters might not seem like a bad thing—after

all, they don’t require us to make that much more effort to understand a test. As

the number of literal values grows, however, it can become much more difﬁ cult

to understand a test. This is especially true when the signal-to-noise ratio drops

dramatically because the majority of the values are irrelevant to the test.

The second major impact occurs when collisions between tests occur because

the tests are using the same values. This situation happens only when we use a

Shared Fixture because a Fresh Fixture strategy shouldn’t litter the scene with

any objects with which a subsequent test can collide.

Obscure Test

Obscure

Test

196

Chapter 15 Code Smells

Possible Solution

The best way to get rid of the Obscure Test smell is to replace the literal constants

with something else. Fixture values that determine which scenario is being ex-

ecuted (e.g., type codes) are probably the only ones that are reasonable to leave as

literals—but even these values can be converted to named constants.

Fixture values that do not matter to the test (i.e., those that do not affect the

expected outcome) should be defaulted within Creation Methods. In this way

we say to the test reader, “The values you don’t see don’t affect the expected

outcome.” We can replace ﬁ xture values that appear in both the ﬁ xture setup

and outcome veriﬁ cation parts of the test with suitably initialized named con-

stants as long as we are using a Fresh Fixture approach to ﬁ xture setup.

Values in the result veriﬁ cation logic that are based on values used in the ﬁ x-

ture or that are used as arguments of the SUT should be replaced with Derived

Values (page 718) to make those calculations obvious to the test reader.

If we are using any variant of Shared Fixture, we should try to use Distinct

Generated Values (see Generated Value on page 723) to ensure that each

time a test is run, it uses a different value. This consideration is especially

important for ﬁ elds that serve as unique keys in databases. A common way of

encapsulating this logic is to use Anonymous Creation Methods (see Creation

Method).

Cause: Indirect Testing

The Test Method interacts with the SUT indirectly via another object, thereby

making the interactions more complex.

Symptoms

A test interacts primarily with objects other than the one whose behavior it

purports to verify. The test must construct and interact with objects that contain

references to the SUT rather than with the SUT itself. Testing business logic

through the presentation layer is a common example of Indirect Testing.

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();

Obscure

Test

197

String actualHtml =

sut.getFlightConnectionAsHtmlFragment(

illegalConn.getInboundFlightNumber(),

illegalConn.getOutboundFlightNumber());

// 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);

}

Impact

It may not be possible to test “anything that could possibly break” in the SUT

via the intermediate object. Indeed, such tests are unlikely to be very clear or

understandable. They certainly will not result in Tests as Documentation.

Indirect Testing may result in Fragile Tests because changes in the intermediate

objects may require modiﬁ cation of the tests even when the SUT is not modiﬁ ed.

Root Cause

The SUT may be “private” to the class being used to access it from the test. It

may not be possible to create the SUT directly because the constructors them-

selves are private. This problem is just one sign that the software is not designed

for testability.

It may be that the actual outcome of exercising the SUT cannot be observed

directly. In such a case, the expected outcome of the test must be veriﬁ ed through

an intermediate object.

Possible Solution

It may be necessary to improve the design-for-testability of the SUT to remove this

smell. We might be able to expose the SUT directly to the test by using an Extract

Testable Component refactoring (a variant of the Sprout Class [WEwLC] refac-

toring). This approach may result in an untestable Humble Object (page 695) and

an easily tested object that contains most or all of the actual logic.

public void testAnalyze_sameAirline_EqualsConnectionLimit()

throws Exception {

// setup

Mock ﬂightMgntStub = mock(FlightManagementFacade.class);

Obscure Test

Obscure

Test