Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
588
Chapter 23 Test Double Patterns
Example: Defi ning Test-Specifi c Equality (Behavior-Modifying
Subclass)
Here is an example of a very simple test that fails because the object we pass
to assertEquals does not implement test-specifi c equality. That is, the default
equals method returns false even though our test considers the two objects to be
equals.
protected void setUp() throws Exception {
oneOutboundFlight = findOneOutboundFlightDto();
}
public void testGetFlights_OneFlight() throws Exception {
// Exercise System
List flights = facade.getFlightsByOriginAirport(
oneOutboundFlight.getOriginAirportId());
// Verify Outcome
assertEquals("Flights at origin - number of flights: ",
1,
flights.size());
FlightDto actualFlightDto = (FlightDto)flights.get(0);
assertEquals("Flight DTOs at origin",
oneOutboundFlight,
actualFlightDto);
}
One option is to write a Custom Assertion (page 474). Another option is to use
a Test-Specifi c Subclass to add a more appropriate defi nition of equality for our
test purposes alone. We can change our fi xture setup code slightly to create the
Test-Specifi c Subclass as our Expected Object (see State Verifi cation).
private FlightDtoTss oneOutboundFlight;
private FlightDtoTss findOneOutboundFlightDto() {
FlightDto realDto = helper.findOneOutboundFlightDto();
return new FlightDtoTss(realDto) ;
}
Finally, we implement the Test-Specifi c Subclass by copying and comparing only
those fi elds that we want to use for our test-specifi c equality.
public class FlightDtoTss extends FlightDto {
public FlightDtoTss(FlightDto realDto) {
this.destAirportId = realDto.getDestinationAirportId();
this.equipmentType = realDto.getEquipmentType();
this.flightNumber = realDto.getFlightNumber();
this.originAirportId = realDto.getOriginAirportId();
}
Test-Specifi c
Subclass
589
public boolean equals(Object obj) {
FlightDto otherDto = (FlightDto) obj;
if (otherDto == null) return false;
if (otherDto.getDestAirportId()!= this.destAirportId)
return false;
if (otherDto.getOriginAirportId()!= this.originAirportId)
return false;
if (otherDto.getFlightNumber()!= this.flightNumber)
return false;
if (otherDto.getEquipmentType() != this.equipmentType )
return false;
return true;
}
}
In this case we copied the fi elds from the real DTO into our Test-Specifi c Subclass,
but we could just as easily have used the Test-Specifi c Subclass as a wrapper for the
real DTO. There are other ways we could have created the Test-Specifi c Subclass;
the only real limit is our imagination.
This example also assumes that we have a reasonable toString implementa-
tion on our base class that prints out the values of the fi elds being compared.
It is needed because assertEquals will use that implementation when the equals
method returns false. Otherwise, we will have no idea of why the objects are
considered unequal.
Example: State-Exposing Subclass
Suppose we have the following test, which requires a Flight to be in a particular
state:
protected void setUp() throws Exception {
super.setUp();
scheduledFlight = createScheduledFlight();
}
Flight createScheduledFlight() throws InvalidRequestException{
Flight newFlight = new Flight();
newFlight.schedule();
return newFlight;
}
public void testDeschedule_shouldEndUpInUnscheduleState()
throws Exception {
scheduledFlight.deschedule();
assertTrue("isUnsched", scheduledFlight.isUnscheduled());
}
Test-Specific Subclass
Test-Specifi c
Subclass
590
Chapter 23 Test Double Patterns
Setting up the fi xture for this test requires us to call the method schedule on the
fl ight:
public class Flight{
protected FlightState currentState = new UnscheduledState();
/**
* Transitions the Flight from the <code>unscheduled</code>
* state to the <code>scheduled</code> state.
* @throws InvalidRequestException when an invalid state
* transition is requested
*/
public void schedule() throws InvalidRequestException{
currentState.schedule();
}
}
The Flight class uses the State [GOF] pattern and delegates handling of the schedule
method to whatever State object is currently referenced by currentState. This test
will fail during fi xture setup if schedule does not work yet on the default content of
currentState. We can avoid this problem by using a State-Exposing Subclass that
provides a method to move directly into the state, thereby making this an Inde-
pendent Test (see page 42).
public class FlightTss extends Flight {
public void becomeScheduled() {
currentState = new ScheduledState();
}
}
By introducing a new method becomeScheduled on the Test-Specifi c Subclass, we
ensure that we will not accidentally override any existing behavior of the SUT.
Now all we have to do is instantiate the Test-Specifi c Subclass in our test instead
of the base class by modifying our Creation Method (page 415).
Flight createScheduledFlight() throws InvalidRequestException{
FlightTss newFlight = new FlightTss();
newFlight.becomeScheduled();
return newFlight;
}
Note how we still declare that we are returning an instance of the Flight class
when we are, in fact, returning an instance of the Test-Specifi c Subclass that has
the additional method.
Test-Specifi c
Subclass
591
Chapter 24
Test Organization Patterns
Patterns in This Chapter
Named Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Test Code Reuse
Test Utility Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Parameterized Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Testcase Class Structure
Testcase Class per Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Testcase Class per Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Testcase Class per Fixture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Utility Method Location
Testcase Superclass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Test Helper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Test
Organization
Patterns
592
Chapter 24 Test Organization Patterns
Named Test Suite
How do we run the tests when we have arbitrary groups of
tests to run?
We defi ne a test suite, suitably named, that contains a set of tests
that we wish to be able to run as a group.
When we have a large number of tests, we need to organize them in a systematic
way. A test suite allows us to group tests that have related functionality close to
each other. Although we want to be able to run all the tests for the entire applica-
tion or component easily, we also want to be able to run only those tests applicable
to specifi c subsets of the functionality or subcomponents of the system. In other
situations, we want to run only a subset of all the tests we have defi ned.
Named Test Suites give us a way to choose which predefi ned subset of the
tests we want to run.
How It Works
For each group of related tests that we would like to be able to run as a group, we
can defi ne a special Test Suite Factory (see Test Enumeration on page 399) with
an Intent-Revealing Name. The Factory Method [GOF] can use any of several
Fixture
Testcase Class
Testcase Object
Implicit setUp
Implicit tearDown
Testcase Object
Implicit setUp
Implicit tearDown
SUT
Test
Suite
Object
testMethod_1
testMethod_n
Test
Suite
Factory
Creation
Fixture
Testcase Class
Testcase Object
Implicit setUp
Implicit tearDown
Testcase Object
Implicit setUp
Implicit tearDown
SUT
Test
Suite
Object
testMethod_1
testMethod_n
Test
Suite
Factory
Creation
Named Test
Suite
593
test suite construction techniques to return a Test Suite Object (page 387)
containing only the specifi c Testcase Objects (page 382) we wish to execute.
When to Use It
Although we often want to run all the tests with a single command, sometimes
we want to run only a subset of the tests. The most common reason for doing so
is time; for this purpose, running the AllTests Suite for a specifi c context is prob-
ably our best bet. When our member of xUnit doesn’t support Test Selection
and the tests we want to run are scattered across multiple contexts and some
contexts contain tests we defi nitely don’t want run, we can use a Subset Suite.
Variation: AllTests Suite
We often want to run all the tests we have available. With smaller systems, it
may be standard practice to run the AllTests Suite after checking out a new code
base (to ensure we start at a known point) and before every check-in (to ensure
all our code works). We typically have an AllTests Suite for each package or
namespace of software so that we can run subsets of the tests after each code
change as part of the “red–green–refactor” cycle.
Variation: Subset Suite
Developers often do not want to run tests because they are Slow Tests (page 253).
Tests that exercise components that access a database will inevitably run much
more slowly than tests that run entirely in memory. By defi ning one Named Test
Suite for the database tests and another Named Test Suite for the in-memory
tests, we can choose not to run the database tests simply by choosing to run the
in-memory Subset Suite.
Another common reason given for not running tests is because the context
they need to run is not available. For example, if we don’t have a Web server
running on our development desktop, or if deploying our software to the Web
server takes too long, we won’t want to run the tests of components that require
the Web server to be running (they would just take extra time to run, and we
know they will fail and spoil our chances of achieving a green bar).
Variation: Single Test Suite
The degenerate form of a Subset Suite is the Single Test Suite, in which we instanti-
ate a single Testcase Object so that we can run a single Test Method (page 348).
This variation is particularly useful when we don’t have a Test Tree Explorer
(see Test Runner on page 377) available or when the Test Method requires some
Named Test
Suite
Named Test Suite
594
Chapter 24 Test Organization Patterns
form of Setup Decorator (page 447) to run properly. Some test automaters keep a
“MyTest” Testcase Class (page 373) open in their workspace at all times specifi -
cally for this purpose.
Implementation Notes
The concept of running named sets of tests is independent of how we build the
Named Test Suites. For example, we can use Test Enumeration to build up our
suites of tests explicitly or we can use Test Discovery (page 393) to fi nd all tests
in a particular place (e.g., a namespace or assembly). We can also do Test Selec-
tion (page 403) from within a suite of tests to create a smaller suite dynamically.
Some members of the xUnit family require us to defi ne the AllTests Suites for
each test package or subsystem manually; others, such as NUnit, automatically
create a Test Suite Object for each namespace.
When we are using Test Enumeration and have Named Test Suites for various
subsets of the tests, it is better to defi ne our AllTests Suite in terms of these subsets.
When we implement the AllTests Suite as a Suite of Suites (see Test Suite Object), we
need to add a new Testcase Class to only a single Named Test Suite; this collection
of tests is then rolled up into the AllTests Suite for the local context as well as the
Named Test Suite and the next higher context.
Refactoring Notes
The steps to refactor existing code to a Named Test Suite are highly dependent
on the variant of Named Test Suite we are using. For this reason, I’ll dispense
with the motivating example and skip directly to examples of Named Test Suites.
Example: AllTests Suite
An AllTests Suite helps us run all the tests for different subsets of the functional-
ity of our choosing. For each subcomponent or context (e.g., a Java package),
we defi ne a special test suite (and its corresponding Test Suite Factory) called
AllTests. In the suite Factory Method on the Test Suite Factory, we add all the
tests in the current context and all the Named Test Suites from any nested con-
texts (such as nested Java packages). That way, when the top-level Named Test
Suite is run, all Named Test Suites for the nested contexts will be run as well.
The following example illustrates the kind of code that would be required to
run all the tests in most members of the xUnit family:
public class AllTests {
public static Test suite() {
Named Test
Suite
595
TestSuite suite = new TestSuite("Test for allJunitTests");
//$JUnit-BEGIN$
suite.addTestSuite(
com.clrstream.camug.example.test.InvoiceTest.class);
suite.addTest(com.clrstream.ex7.test.AllTests.suite());
suite.addTest(com.clrstream.ex8.test.AllTests.suite());
suite.addTestSuite(
com.xunitpatterns.guardassertion.Example.class);
//$JUnit-END$
return suite;
}
}
We had to use a mix of methods in this case because we are adding other Named
Test Suites as well as Test Suite Objects representing a single Testcase Class. In
JUnit, we use different methods to do this. Other members of the xUnit family,
however, may use the same method signature.
The other notable aspect of this example is the JUnit-start and JUnit-end com-
ments. The IDE (in this case, Eclipse) helps us out by automatically regener-
ating the list between these two comments—a semi-automated form of Test
Discovery.
Example: Special-Purpose Suite
Suppose we have three major packages (A, B, and C) containing business logic.
Each package contains both in-memory objects and database access classes. We
would then have corresponding test packages for each of the three packages.
Some tests in each package would require the database, while others could run
purely in memory.
We want to be able to run the following sets of tests for the entire system,
and for each package (A, B, and C):
• All tests
• All database tests
• All in-memory tests
This implies a total of 12 named sets of tests (three named sets for each of four
contexts).
In each of the three packages (A, B, and C), we should defi ne the following
Named Test Suites:
Named Test
Suite
Named Test Suite
596
Chapter 24 Test Organization Patterns
• AllDbTests, by adding all the Testcase Classes containing database tests
• AllInMemoryTests, by adding all the Testcase Classes containing in-memory
tests
• AllTests, by combining AllDbTests and AllInMemoryTests
Then, at the top-level testing context, we defi ne Named Test Suites by the same
names as follows:
• AllDbTests, by composing all the AllDbTests Testcase Classes from pack-
ages A, B, and C
• AllInMemoryTests, by composing all the AllInMemoryTests Testcase Classes
from packages A, B, and C
• AllTests, by composing all the AllTests Testcase Classes from packages
A, B, and C (This is just the normal AllTests Suite.)
If we fi nd ourselves needing to include some tests from a single Testcase Class in
both Named Test Suites, we should split the class into one class for each context
(e.g., database tests and in-memory tests).
Example: Single Test Suite
In some circumstances—especially when we are using a debugger—it is highly
desirable to not run all the tests in a Testcase Class. One way to run only a subset of
these tests is to use the Test Tree Explorer provided by some Graphical Test Run-
ners (see Test Runner). When this capability isn’t available, a common practice is
to disable the tests we don’t want run by either commenting them out, copying the
entire Testcase Class and deleting most of the tests, or changing the names or attri-
butes of the test that cause them to be included by the Test Discovery algorithm.
public class LostTests extends TestCase {
public LostTests(String name) {
super(name);
}
public void xtestOne() throws Exception {
fail("test not implemented");
}
/*
public void testTwo() throws Exception {
fail("test not implemented");
}
*/
Named Test
Suite
597
public void testSeventeen() throws Exception {
assertTrue(true);
}
}
All of these approaches suffer from the potential for Lost Tests (see Produc-
tion Bugs on page 268) if the means of running a single test is not reversed
properly when the situation requiring this testing strategy has passed. A Sin-
gle Test Suite makes it possible to run the specifi c test(s) without making any
changes to the Testcase Class in question. This technique takes advantage of the
fact that most implementations of xUnit require a one-argument constructor on
our Testcase Class; this argument consists of the name of the method that this
instance of the class will invoke using refl ection. The one-argument construc-
tor is called once for each Test Method on the class, and the resulting Testcase
Object is added to the Test Suite Object. (This is an example of the Pluggable
Behavior [SBPP] pattern.)
We can run a single test by implementing a Test Suite Factory class with a
single method suite that creates an instance of the desired Testcase Class by call-
ing the one-argument constructor with the name of the one Test Method to be
run. By returning a Test Suite Object containing only this one Testcase Object
from suite, we achieve the desired result (running a single test) without touching
the target Testcase Class.
public class MyTest extends TestCase {
public static Test suite() {
return new LostTests("testSeventeen");
}
}
I like to keep a Single Test Suite class around all the time and just plug in what-
ever test I want to run by changing the import statements and the suite method.
Often, I maintain several Single Test Suite classes so I can fl ip back and forth
between different tests very quickly. I fi nd this technique easier to do than drill-
ing down in the Test Tree Explorer and picking the specifi c test to run manually.
(Your mileage may vary!)
Example: Smoke Test Suite
We can take the idea of a Special-Purpose Suite and combine it with the imple-
mentation technique of a Single Test Suite to create a Smoke Test [SCM] suite.
This strategy involves picking a representative test or two from each of the major
areas of the system and including those tests in a single Test Suite Object.
Named Test
Suite
Named Test Suite