Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
488
Chapter 21 Result Verification Patterns
Motivating Example
The following test retrieves some objects from the SUT. It then compares the
objects it actually found with the objects it expected to fi nd.
public void testGetFlightsByOriginAirport_OneOutboundFlight()
throws Exception {
FlightDto expectedFlightDto =
createNewFlightBetweenExistingAirports();
// Exercise System
facade.createFlight(
expectedFlightDto.getOriginAirportId(),
expectedFlightDto.getDestinationAirportId());
// Verify Outcome
List flightsAtOrigin = facade.getFlightsByOriginAirport(
expectedFlightDto.getOriginAirportId());
assertOnly1FlightInDtoList( "Outbound flight at origin",
expectedFlightDto,
flightsAtOrigin);
}
Unfortunately, because this test used a Shared Fixture, other tests that ran before
it may have added objects as well. That behavior could cause the current test to
fail if we encounter additional, unexpected objects.
Refactoring Notes
To convert the test to use a Delta Assertion, we must fi rst take a snapshot of
the data (or collection of objects) we will later be asserting on. Next, we need
to modify our assertions to focus on the difference between the pre-test data/
objects and the post-test data/objects. To avoid introducing Conditional Test
Logic (page 200) into the Test Method (page 348), we may want to introduce
a new Custom Assertion. Although we may be able to use existing assertions
(custom or otherwise) as a starting point, we’ll probably have to modify them to
take the pre-test data into account.
Example: Delta Assertion
In this version of the test, we use a Delta Assertion to verify the objects added
when we exercised the SUT. Here we are verifying that we have one more object
than before and that the collection of objects returned by the SUT includes the
new Expected Object and all objects that it previously contained.
public void testCreateFlight_Delta()
throws Exception {
FlightDto expectedFlightDto =
createNewFlightBetweenExistingAirports();
Delta
Assertion
489
// Remember prior state
List flightsBeforeCreate =
facade.getFlightsByOriginAirport(
expectedFlightDto.getOriginAirportId());
// Exercise system
facade.createFlight(
expectedFlightDto.getOriginAirportId(),
expectedFlightDto.getDestinationAirportId());
// Verify outcome relative to prior state
List flightsAfterCreate =
facade.getFlightsByOriginAirport(
expectedFlightDto.getOriginAirportId());
assertFlightIncludedInDtoList( "new flight ",
expectedFlightDto,
flightsAfterCreate);
assertAllFlightsIncludedInDtoList( "previous flights",
flightsBeforeCreate,
flightsAfterCreate);
assertEquals( "Number of flights after create",
flightsBeforeCreate.size()+1,
flightsAfterCreate.size());
}
Because the SUT returns Data Transfer Objects [CJ2EEP], we can be assured
that the objects we saved before exercising the SUT cannot possibly change.
We have modifi ed our Custom Assertions to ignore the pre-test objects (by not
insisting that the Expected Object is the only one) and have written a new Cus-
tom Assertion that ensures all pre-test objects are also present. Another way to
accomplish this task is to remove the pre-test objects from the result collection
and then verify that only the new Expected Objects are left.
I’ve omitted the implementation of the Custom Assertions, as it is purely
an exercise in comparing objects and is not salient to understanding the Delta
Assertion pattern. The “test infected” among us would, of course, write the Custom
Assertions driven by some Custom Assertion Tests (see Custom Assertion).
Delta Assertion
Delta
Assertion
490
Chapter 21 Result Verification Patterns
Guard Assertion
How do we avoid Conditional Test Logic?
We replace an if statement in a test with an assertion that fails the test
if not satisfi ed.
Some verifi cation logic may fail because information returned by the SUT is not
initialized as expected. When a test encounters an unexpected problem, it may
produce a test error rather than a test failure. While the Test Runner (page 377)
does its best to provide useful diagnostic information, the test automater can of-
ten do better by checking for the particular condition and reporting it explicitly.
A Guard Assertion is a good way to do so without introducing Conditional
Test Logic (page 200).
How It Works
Tests either pass or fail. We fail tests by calling Assertion Methods (page 362)
that stop the test from executing further if the assertion’s condition is not met.
Alternatively, we can replace Conditional Test Logic that is used to avoid ex-
ecuting assertions when they would cause test errors with assertions that fail the
test instead. This pattern also documents the fact that we expect the condition of
the Guard Assertion to be true. A failure of the Guard Assertion makes it very
Fixture
Setup
Exercise
Verify
Teardown
SUT
Assert
AssertNotNull
obj
obj.attr
Fixture
Setup
Exercise
Verify
Teardown
SUT
Assert
AssertNotNull
obj
obj.attr
Guard
Assertion
491
clear that some condition we expected to be true was not; it eliminates the effort
needed to infer the test result from the conditional logic.
When to Use It
We should use a Guard Assertion whenever we want to avoid executing state-
ments in our Test Method (page 348) because they would cause an error if they
were executed when some condition related to values returned by the SUT is not
true. We take this step instead of putting an if then else fail code construct around
the sensitive statements. Normally, a Guard Assertion is placed between the exer-
cise SUT and the verify outcome phases of a Four-Phase Test (page 358).
Variation: Shared Fixture State Assertion
When the test uses a Shared Fixture (page 317), a Guard Assertion can also be
useful at the beginning of the test (before the exercise SUT phase) to verify that
the Shared Fixture satisfi es the test’s needs. It also makes it clearer to the test
reader which parts of the Shared Fixture this test actually uses; the greater clar-
ity improves the likelihood of achieving Tests as Documentation (see page 23).
Implementation Notes
We can use Stated Outcome Assertions (see Assertion Method) like assertNotNil and
Equality Assertions (see Assertion Method) like assertEquals as Guard Assertions
that fail the test and prevent execution of other statements that would cause test
errors.
Motivating Example
Consider the following example:
public void testWithConditionals() throws Exception {
String expectedLastname = "smith";
List foundPeople = PeopleFinder.
findPeopleWithLastname(expectedLastname);
if (foundPeople != null) {
if (foundPeople.size() == 1) {
Person solePerson = (Person) foundPeople.get(0);
assertEquals( expectedLastname,solePerson.getName());
} else {
fail("list should have exactly one element");
}
} else {
fail("list is null");
}
}
Guard Assertion
Guard
Assertion
492
Chapter 21 Result Verification Patterns
This example includes plenty of conditional statements that the author might get
wrong—things like writing (foundPeople == null) instead of (foundPeople != null). In
C-based languages, one might mistakenly use = instead of ==, which would result
in the test always passing!
Refactoring Notes
We can use a Replace Nested Conditional with Guard Clauses [Fowler] refactoring
to transform this spider web of Conditional Test Logic into a nice linear sequence
of statements. (In a test, even a single conditional statement is considered too much
and hence “nested”!) We can use Stated Outcome Assertions to check for null
object references and Equality Assertions to verify the number of objects in the
collection. If each assertion is satisfi ed, the test proceeds. If they are not satisfi ed,
the test ends in failure before it reaches the next statement.
Example: Simple Guard Assertion
This simplifi ed version of the test replaces all conditional statements with asser-
tions. It is shorter than the original test and much easier to read.
public void testWithoutConditionals() throws Exception {
String expectedLastname = "smith";
List foundPeople = PeopleFinder.
findPeopleWithLastname(expectedLastname);
assertNotNull("found people list", foundPeople);
assertEquals( "number of people", 1, foundPeople.size() );
Person solePerson = (Person) foundPeople.get(0);
assertEquals( "last name",
expectedLastname,
solePerson.getName() );
}
We now have a single linear execution path through this Test Method (page 348);
it should improve our confi dence in the correctness of this test immensely!
Example: Shared Fixture Guard Assertion
Here’s an example of a test that depends on a Shared Fixture. If a previous test (or
even this test in a previous test run) modifi es the state of the fi xture, our SUT could
return unexpected results. It might take a fair bit of effort to determine that the
problem lies in the test’s pre-conditions rather than being a bug in the SUT. We can
avoid all of this trouble by making the assumptions of this test explicit through the
use of a Guard Assertion during the fi xture lookup phase of the test.
Guard
Assertion
493
public void testAddFlightsByFromAirport_OneOutboundFlight_GA()
throws Exception {
// Fixture Lookup
List flights = facade.getFlightsByOriginAirport(
ONE_OUTBOUND_FLIGHT_AIRPORT_ID );
// Guard Assertion on Fixture Contents
assertEquals( "# flights precondition", 1, flights.size());
FlightDto firstFlight = (FlightDto) flights.get(0);
// Exercise System
BigDecimal flightNum = facade.createFlight(
firstFlight.getOriginAirportId(),
firstFlight.getDestAirportId());
// Verify Outcome
FlightDto expFlight = (FlightDto) firstFlight.clone();
expFlight.setFlightNumber( flightNum );
List actual = facade.getFlightsByOriginAirport(
firstFlight.getOriginAirportId());
assertExactly2FlightsInDtoList( "Flights at origin",
firstFlight,
expFlight,
actual);
}
We now have a way to determine that the assumptions were violated without
extensive debugging! This is another way we achieve Defect Localization (see
page 22). This time the defect is in the tests’ assumptions on the previously run
tests’ behavior.
Guard Assertion
Guard
Assertion
494
Chapter 21 Result Verification Patterns
Unfi nished Test Assertion
How do we structure our test logic to avoid leaving tests unfi nished?
We ensure that incomplete tests fail by executing an assertion
that is guaranteed to fail.
void testSomething() {
// Outline:
// create a flight in ... state
// call the ... method
// verify flight is in ... state
fail("Unfinished Test!");
}
When we start defi ning the tests for a particular piece of code, it is useful to
“rough in” the tests by defi ning Test Methods (page 348) on the appropriate
Testcase Class (page 373) as we think of the test conditions. We do, however,
want to ensure that we don’t accidentally forget to fi ll in the bodies of these tests
if we get distracted. We want the tests to fail until we fi nish coding them.
Including an Unfi nished Test Assertion is a good way to make sure we don’t
forget.
How It Works
We put a single call to fail in each Test Method as we defi ne it. The fail method is
a Single-Outcome Assertion (see Assertion Method on page 362) that always fails.
We include the Assertion Message (page 370) “Unfi nished Test” as a reminder of
why the test fails when we do run the tests.
When to Use It
We should not deliberately write any tests that might accidentally pass. A failing
test makes a good reminder that we still have work to do. We can remind our-
selves of this work by putting an Unfi nished Test Assertion
at the end of every
test we write and by removing it only when we are satisfi ed that the test is coded
properly. There is no real cost to doing so, but a lot of benefi t. It is just a matter
of getting into the habit. Some IDEs even help us out by letting us put the Unfi n-
ished Test Assertion into the code generation template for a Test Method
If we need to check in the tests before all code is working, we shouldn’t remove
the tests or the Unfi nished Test Assertions just to get a green bar, as this could
Unfi nished
Test
Assertion
495
result in Lost Tests (see Production Bugs on page 268). Instead, we can add an
[Ignore] attribute to the test if our member of the xUnit family supports it, rename
the test method if xUnit uses name-based Test Discovery (page 393), or exclude
the entire Testcase Class from the AllTests Suite (see Named Test Suite on page
592) if we are using Test Enumeration (page 399) at the suite level.
Implementation Notes
Most members of the xUnit family have a fail method already defi ned. If the
member that we are using doesn’t include it, we should avoid the temptation
to sprinkle assertTrue(false) throughout our code. This kind of code is obtuse
and easy to get wrong because it is counter-intuitive. Instead, we should take
a minute to write this method ourselves as a Custom Assertion (page 474) and
write the Custom Assertion Test (see Custom Assertion) for it fi rst to make sure
we got it right.
Some IDEs include the ability to customize code generation templates. Some
even include a template for a Test Method that includes an Unfi nished Test
Assertion.
Motivating Example
Consider the following Testcase Class that we are roughing in:
public void testPull_emptyStack() {
}
public void testPull_oneItemOnStack () {
}
public void testPull_twoItemsOnStack () {
//To do: Write this test
}
public void testPull_oneItemsRemainingOnStack () {
//To do: Write this test
}
Including the // To do: ... comments may remind us that the test still needs work
if our IDE supports that feature—but it won’t remind us of the unfi nished work
when we run the tests. Running this Testcase Class will result in a green bar even
though we may not have implemented our stack at all!
Unfinished Test Assertion
Unfi nished
Test
Assertion
496
Chapter 21 Result Verification Patterns
Refactoring Notes
To implement Unfi nished Test Assertion all we need to do is add the following
line to each test as we rough it in:
fail("Unfinished Test!");
The exclamation mark is optional. It might be even better to create a Custom
Assertion such as this one:
private void unfinishedTest() {
fail("Test not implemented!");
}
This would allow us to fi nd all the Unfi nished Test Assertions easily by using the
“search for references” feature of our IDE.
Example: Unfi nished Test Assertion
Here are the tests with an Unfi nished Test Assertion added to each one:
public void testPull_emptyStack() {
unfinishedTest();
}
public void testPull_oneItemOnStack () {
unfinishedTest();
}
public void testPull_twoItemsOnStack() {
unfinishedTest();
}
public void testPull_oneItemsRemainingOnStack () {
unfinishedTest();
}
Now we have a Testcase Class that is guaranteed to fail until we fi nish writing
the code. The failing tests act as a “to do” list for writing the tests.
Example: Unfi nished Test Method Generation from Template
Eclipse (version 3.0) is an example of an IDE that includes the ability to custom-
ize templates. Its testmethod template inserts the following code into our Testcase
Class:
public void testname() throws Exception {
fail("ClassName::testname not implemented");
}
Unfi nished
Test
Assertion
497
The strings “ClassName” and “testname” are placeholders for the names of the
Testcase Class and Test Method, respectively; they are fi lled in automatically
by the IDE. As we modify the test name in the signature, the test name in the
fail statement is adjusted automatically. All we have to do to insert a new Test
Method into a class is to type “testmethod” and then press CTRL-SPACEBAR.
Unfinished Test Assertion
Unfi nished
Test
Assertion