Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
198
Chapter 15 Code Smells
Flight firstFlight = createFlight();
Flight secondFlight = createConnectingFlight(
firstFlight, LEGAL_CONN_MINS_SAME);
flightMgntStub.expects(once()).method("getFlight")
.with(eq(firstFlight.getFlightNumber()))
.will(returnValue(firstFlight));
flightMgntStub.expects(once()).method("getFlight")
.with(eq(secondFlight.getFlightNumber()))
.will(returnValue(secondFlight));
// exercise
FlightConnAnalyzer theConnectionAnalyzer =
new FlightConnAnalyzer();
theConnectionAnalyzer.facade =
(FlightManagementFacade)flightMgntStub.proxy();
FlightConnection actualConnection =
theConnectionAnalyzer.getConn(
firstFlight.getFlightNumber(),
secondFlight.getFlightNumber());
// verification
assertNotNull("actual connection", actualConnection);
assertTrue("IsLegal", actualConnection.isLegal());
}
Sometimes we may be forced to interact with the SUT indirectly because we
cannot refactor the code to expose the logic we are trying to test. In these cases,
we should encapsulate the complex logic forced by Indirect Testing behind suit-
ably named Test Utility Methods. Similarly, fi xture setup can be hidden behind
Creation Methods and result verifi cation can be hidden by Verifi cation Methods
(see Custom Assertion). Both are examples of SUT API Encapsulation (see Test
Utility Method).
public void testAnalyze_sameAirline_LessThanConnLimit()
throws Exception {
// setup
FlightConnection illegalConn =
createSameAirlineConn( LEGAL_CONN_MINS_SAME - 1);
FlightConnectionAnalyzerImpl sut =
new FlightConnectionAnalyzerImpl();
// exercise SUT
String actualHtml =
sut.getFlightConnectionAsHtmlFragment(
illegalConn.getInboundFlightNumber(),
illegalConn.getOutboundFlightNumber());
// verification
assertConnectionIsIllegal(illegalConn, actualHtml);
}
The following Custom Assertion hides the ugliness of extracting the business
result from the presentation noise. It was created by doing a simple Extract Method
[Fowler] refactoring on the test. Of course, this example would be more robust
Obscure
Test
199
if it searched inside the HTML for key strings rather than building up the entire
expected string and comparing it all at once. Other Presentation Layer Tests (see
Layer Test on page 337) might then verify that the presentation logic is format-
ting the HTML string properly.
private void assertConnectionIsIllegal( FlightConnection conn,
String actualHtml) {
// set up expected value
StringBuffer expected = new StringBuffer();
expected.append("<span class="boldRedText">");
expected.append("Connection time between flight ");
expected.append(conn.getInboundFlightNumber());
expected.append(" and flight ");
expected.append(conn.getOutboundFlightNumber());
expected.append(" is ");
expected.append(conn.getActualConnectionTime());
expected.append(" minutes.</span>");
// verification
assertEquals("html", expected.toString(), actualHtml);
}
Solution Patterns
A good test strategy helps keep the test code understandable. Nevertheless, just
as “no battle plan survives the fi rst contact with the enemy,” no test infrastruc-
ture can anticipate all needs of all tests. We should expect the test infrastructure
to evolve as the software matures and our test automation skills improve.
We can reuse test logic for several scenarios by having several tests call Test
Utility Methods or by asking a common Parameterized Test (page 607) to pass
in the already built test fi xture or Expected Objects.
Writing tests in an “outside-in” way can minimize the likelihood of produc-
ing an Obscure Test that might then need to be refactored. This approach starts
by outlining the Four-Phase Test using calls to nonexistent Test Utility Meth-
ods. Once we are satisfi ed with these tests, we can write the utility methods
needed to run them. By writing the tests fi rst, we gain a better understanding of
what the utility methods need to do for us to make writing the tests as simple
as possible. The “test-infected” will, of course, write Test Utility Tests (see Test
Utility Method) before writing the Test Utility Methods.
Obscure Test
Obscure
Test
200
Chapter 15 Code Smells
Conditional Test Logic
A test contains code that may or may not be executed.
A Fully Automated Test (see page 26) is just code that verifi es the behavior of
other code. But if this code is complicated, how do we verify that it works prop-
erly? We could write tests for our tests—but when would this recursion stop?
The simple answer is that Test Methods (page 348) must be simple enough to
not need tests.
Conditional Test Logic is one factor that makes tests more complicated than
they really should be.
Symptoms
As a code smell, Conditional Test Logic may not produce any behavioral symp-
toms but its presence should be reasonably obvious to the test reader. View
any control structures within a Test Method with extreme suspicion! The test
reader may also wonder which code path is the one that is being executed. The
following is an example of Conditional Test Logic that involves both looping
and
if statements:
// verify Vancouver is in the list
actual = null;
i = flightsFromCalgary.iterator();
while (i.hasNext()) {
FlightDto flightDto = (FlightDto) i.next();
if (flightDto.getFlightNumber().equals(
expectedCalgaryToVan.getFlightNumber()))
{
actual = flightDto;
assertEquals("Flight from Calgary to Vancouver",
expectedCalgaryToVan,
flightDto);
break;
}
}
}
This code begs the question, “What is this test code doing and how do we
know that it is doing it correctly?” One behavioral symptom may be the pres-
ence of the related project-level smell High Test Maintenance Cost (page 265),
which may be caused by the complexity introduced by the Conditional Test
Logic.
Also known as:
Indented Test
Code
Conditional
Test Logic
201
Impact
Conditional Test Logic makes it diffi cult to know exactly what a test is going
to do when it really matters. Code that has only a single execution path al-
ways executes in exactly the same way. Code that has multiple execution paths
presents much greater challenges and does not inspire as much confi dence
about its outcome.
To increase our confi dence in production code, we can write Self-Checking
Tests (see page 26) that exercise the code. How can we increase our confi dence
in the test code if it executes differently each time we run it? It is hard to know
(or prove) that the test is verifying the behavior we want it to verify. A test that
has branches or loops, or that uses different values each time it is run, can be
very diffi cult to debug simply because it isn’t completely deterministic.
A related issue is that Conditional Test Logic makes writing the test correctly
a more diffi cult task. Because the test itself cannot be tested easily, how do we
know that it will actually detect the bugs it is intended to catch? [This is a gen-
eral problem with Obscure Tests (page 186); they are more likely to result in
Buggy Tests (page 260) than simple code.]
Causes
Test automaters may introduce Conditional Test Logic for several reasons:
• They may use if statements to steer execution to a fail statement or to
avoid executing certain pieces of test code when the SUT fails to return
valid data.
• They may use loops to verify the contents of collections of objects
(Conditional Verifi cation Logic). This may also result in an Obscure
Test.
• They may use Conditional Test Logic to verify complex objects or
polymorphic data structures (another form of Conditional Verifi cation
Logic). This is just a Foreign Method [Fowler] implementation of the
equals method.
• They may use Conditional Test Logic to initialize the test fi xture or
Expected Object (see State Verifi cation on page 462) so they can reuse
a single test to verify several different cases (Flexible Test).
• They may use if statements to avoid tearing down nonexistent fi xture
objects (Complex Teardown).
Conditional Test Logic
Conditional
Test Logic
Chapter 15 Code Smells
Some of these causes are worth examining in more detail.
Cause: Flexible Test
The test code verifi es different functionality depending on when or where it is
run.
Symptoms
The test contains conditional logic that does different things depending on the
current environment. Most commonly this functionality takes the form of Con-
ditional Test Logic to build different versions of the expected results based on
some factor external to the test.
Consider the following test, which gets the current time so that it can deter-
mine what the output of the SUT should be:
public void testDisplayCurrentTime_whenever() {
// fixture setup
TimeDisplay sut = new TimeDisplay();
// exercise SUT
String result = sut.getCurrentTimeAsHtmlFragment();
// verify outcome
Calendar time = new DefaultTimeProvider().getTime();
StringBuffer expectedTime = new StringBuffer();
expectedTime.append("<span class=\"tinyBoldText\">");
if ((time.get(Calendar.HOUR_OF_DAY) == 0)
&& (time.get(Calendar.MINUTE) <= 1)) {
expectedTime.append( "Midnight");
} else if ((time.get(Calendar.HOUR_OF_DAY) == 12)
&& (time.get(Calendar.MINUTE) == 0)) { // noon
expectedTime.append("Noon");
} else {
SimpleDateFormat fr = new SimpleDateFormat("h:mm a");
expectedTime.append(fr.format(time.getTime()));
}
expectedTime.append("</span>");
assertEquals( expectedTime, result);
}
Root Cause
A Flexible Test is caused by a lack of control of the environment. The test
automater probably wasn’t able to decouple the SUT from its dependencies and
decided to adapt the test logic based on the state of the environment.
Conditional
Test Logic
202
203
Impact
The fi rst issue is that using a Flexible Test makes the test harder to understand
and therefore to maintain. The second issue is that we don’t know which test
scenarios are actually being exercised and whether all scenarios are, in fact,
exercised regularly. For example, in our sample test, is the midnight scenario
ever exercised? How often? Probably rarely, if ever, because the test would have
to be run at exactly midnight—an unlikely event, even if we timed the nightly
build such that it ran over midnight.
Possible Solution
A Flexible Test is best addressed by decoupling the SUT from whatever depen-
dencies prompted the test automater to make the test fl exible. This involves
refactoring the SUT to support substitutable dependency. We can then replace
the dependency with a Test Double (page 522), such as a Test Stub (page 529) or
Mock Object (page 544), and write separate tests for each circumstance previ-
ously covered by the Flexible Test.
Cause: Conditional Verifi cation Logic
Conditional Test Logic (page 200) may also create problems when it is used to
verify the expected outcome. This issue usually arises when the tester tries to pre-
vent the execution of assertions if the SUT fails to return the right objects or uses
loops to verify the contents of collections returned by the SUT.
// verify Vancouver is in the list
actual = null;
i = flightsFromCalgary.iterator();
while (i.hasNext()) {
FlightDto flightDto = (FlightDto) i.next();
if (flightDto.getFlightNumber().equals(
expectedCalgaryToVan.getFlightNumber()))
{
actual = flightDto;
assertEquals("Flight from Calgary to Vancouver",
expectedCalgaryToVan,
flightDto);
break;
}
}
}
Possible Solution
We can replace the if statements that steer execution to a call to fail with a Guard
Assertion (page 490) that causes the test to fail before we reach the code we don’t
Conditional Test Logic
Conditional
Test Logic
204
Chapter 15 Code Smells
want to execute. This works well unless the test is an Expected Exception Test (see
Test Method.) In the latter case, we should use the standard Expected Exception
Test coding idiom for the xUnit family member and language.
We can replace Conditional Test Logic for verifi cation of complex objects
with an Equality Assertion (see Assertion Method on page 362) on an Expected
Object. If the production code’s equals method is too strict, we can use a Custom
Assertion (page 474) to defi ne test-specifi c equality.
We should move any loops in the verifi cation logic to a Custom Assertion.
We can then verify this assertion’s behavior by using Custom Assertion Tests
(see Custom Assertion).
We can reuse test logic in several tests by calling a Test Utility Method (page 599)
or a common Parameterized Test (page 607) that passes in the already built test
fi xture and Expected Objects.
Cause: Production Logic in Test
Symptoms
Some forms of Conditional Test Logic are found in the result verifi cation section
of our tests. Let us look more closely inside the loops of this test:
public void testCombinationsOfInputValues() {
// Set up fixture
Calculator sut = new Calculator();
int expected; // TBD inside loops
for (int i = 0; i < 10; i++) {
for (int j = 0; j < 10; j++) {
// Exercise SUT
int actual = sut.calculate( i, j );
// Verify result
if (i==3 & j==4) // special case
expected = 8;
else
expected = i+j;
assertEquals(message(i,j), expected, actual);
}
}
}
private String message(int i, int j) {
return "Cell( " + String.valueOf(i)+ ","
+ String.valueOf(j) + ")";
}
Conditional
Test Logic
205
The nested loops in this Loop-Driven Test (see Parameterized Test) exercise the
SUT with various combinations of values of i and j as inputs. Here we will focus
on the Conditional Test Logic inside the loop.
Root Cause
This Production Logic in Test is a direct result of wanting to verify multiple
test conditions in a single Test Method. Given that multiple input values are
passed to the SUT, we should also have multiple expected results. It is hard to
enumerate the expected result for each set of inputs if we pass in many com-
binations of several input arguments to the SUT in nested loops. A common
solution to this problem is to use a Calculated Value (see Derived Value on
page 718) based on the inputs. The potential downfall (as we see here) is that
we fi nd ourselves replicating the expected SUT logic inside our test to calculate
the expected values for assertions.
Possible Solution
If at all possible, it is better to enumerate the sets of precalculated values with
which to test the SUT. The following example tests the same logic using a
(smaller) set of enumerated values:
public void testMultipleValueSets() {
// Set Up Fixture
Calculator sut = new Calculator();
TestValues[] testValues = {
new TestValues(1,2,3),
new TestValues(2,3,5),
new TestValues(3,4,8), // special case!
new TestValues(4,5,9)
};
for (int i = 0; i < testValues.length; i++) {
TestValues values = testValues[i];
// Exercise SUT
int actual = sut.calculate( values.a, values.b);
// Verify Result
assertEquals(message(i), values.expectedSum, actual);
}
}
private String message(int i) {
return "Row "+ String.valueOf(i);
}
Conditional Test Logic
Conditional
Test Logic
206
Chapter 15 Code Smells
Cause: Complex Teardown
Symptoms
Complex fi xture teardown code is more likely to leave the test environment cor-
rupted if it does not clean up after itself correctly. It is hard to verify that tear-
down code has been written correctly, and such code can easily result in “data
leaks” that may later cause this or other tests to fail for no apparent reason.
Consider this example:
public void testGetFlightsByOrigin_NoInboundFlight_SMRTD()
throws Exception {
// Set Up Fixture
BigDecimal outboundAirport = createTestAirport("1OF");
BigDecimal inboundAirport = null;
FlightDto expFlightDto = null;
try {
inboundAirport = createTestAirport("1IF");
expFlightDto =
createTestFlight(outboundAirport, inboundAirport);
// Exercise System
List flightsAtDestination1 =
facade.getFlightsByOriginAirport(inboundAirport);
// Verify Outcome
assertEquals(0,flightsAtDestination1.size());
} finally {
try {
facade.removeFlight(expFlightDto.getFlightNumber());
} finally {
try {
facade.removeAirport(inboundAirport);
} finally {
facade.removeAirport(outboundAirport);
}
}
}
}
Root Cause
Teardown is typically required only when we use persistent resources that are
beyond the reach of our garbage collection system. Complex Teardown occurs
when many such resources are used in the same Test Method.
Possible Solution
To avoid complex teardown logic, we should use Implicit Teardown (page 516),
which will make the code both reusable and testable, or Automated Tear-
down (page 503), which can be verifi ed with automated unit tests. We can
Conditional
Test Logic
207
also eliminate the need to tear down any fi xture objects by using a Fresh
Fixture (page 311) strategy and by avoiding the use of any persistent objects
in our tests by using some sort of Test Double.
Cause: Multiple Test Conditions
Symptoms
A test tries to apply the same test logic to many sets of input values, each with
its own corresponding expected result. In the following example, the test iterates
over a collection of test values and applies the test logic to each set:
public void testMultipleValueSets() {
// Set Up Fixture
Calculator sut = new Calculator();
TestValues[] testValues = {
new TestValues(1,2,3),
new TestValues(2,3,5),
new TestValues(3,4,8), // special case!
new TestValues(4,5,9)
};
for (int i = 0; i < testValues.length; i++) {
TestValues values = testValues[i];
// Exercise SUT
int actual = sut.calculate( values.a, values.b);
// Verify Outcome
assertEquals(message(i), values.expectedSum, actual);
}
}
private String message(int i) {
return "Row "+ String.valueOf(i);
}
Root Cause
The test automater is trying to test many test conditions using the same test logic in
a single Test Method. In the preceding example, it is fairly simple Conditional Test
Logic. Matters could be a lot worse if the code contained multiple nested loops and
maybe even if statements to calculate different cases of the expected values.
Possible Solution
Of all sources of Conditional Test Logic, Multiple Test Conditions is prob-
ably the most innocuous. Other than scaring the test reader, the main impact
of such a test is that it stops executing at the fi rst failure and doesn’t provide
Defect Localization (see page 22) when a bug is introduced into the code. The
Conditional Test Logic
Conditional
Test Logic