Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
628
Chapter 24 Test Organization Patterns
which Test Methods should go into each one. If some Testcase Classes will end
up being smaller than others, it makes the job easier if we start by building the
smaller classes. Next, we do an Extract Class [Fowler] refactoring to create
one of the new Testcase Classes and give it a name that describes the feature it
exercises. Then, we do a Move Method [Fowler] refactoring (or a simple “cut
and paste”) on each Test Method that belongs in this new class along with any
instance variables it uses.
We repeat this process until we are down to just one feature in the original
Testcase Class; we then rename that class based on the feature it exercises. At
this point, each of the Testcase Classes should compile and run—but we still
aren’t completely done. To get the full benefi t of the Testcase Class per Feature
pattern, we have one fi nal step to carry out. We should do a Rename Method
[Fowler] refactoring on each of the Test Methods to better refl ect what the Test
Method is verifying. As part of this refactoring, we can remove any mention
of the feature being exercised from each Test Method name—that informa-
tion should be captured in the name of the Testcase Class. This leaves us with
“room” to include both the starting state (the fi xture) and the expected result
in the method name. If we have multiple tests for each feature with different
method arguments, we’ll need to fi nd a way to include those aspects of the
test conditions in the method name, too.
Another way to perform this refactoring is simply to make copies of the orig-
inal Testcase Class and rename them as described above. Then we simply delete
the Test Methods that aren’t relevant for each class. We do need to be careful
that we don’t delete all copies of a Test Method; a less critical oversight is to
leave a copy of the same method in several Testcase Classes. We can avoid both
of the potential errors by making one copy of the original Testcase Class for
each of the features and rename them as described above. Then we simply de-
lete the Test Methods that aren’t relevant for each class. When we are done, we
simply delete the original Testcase Class.
Example: Testcase Class per Feature
In this example, we have converted the previously mentioned set of tests to use
Testcase Class per Feature.
public class TestScheduleFlight extends TestCase {
public void testUnscheduled_shouldEndUpInScheduled()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInUnscheduledState();
flight.schedule();
assertTrue( "isScheduled()", flight.isScheduled());
Testcase
Class per
Feature
629
}
public void testScheduledState_shouldThrowInvalidRequestEx()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInScheduledState();
try {
flight.schedule();
fail("not allowed in scheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"schedule",
e.getRequest());
assertTrue( "isScheduled()", flight.isScheduled());
}
}
public void testAwaitingApproval_shouldThrowInvalidRequestEx()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInAwaitingApprovalState();
try {
flight.schedule();
fail("not allowed in scheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"schedule",
e.getRequest());
assertTrue( "isAwaitingApproval()",
flight.isAwaitingApproval());
}
}
}
Except for their names, the Test Methods really haven’t changed here. Because the
names include the pre-conditions (fi xture), the feature being exercised, and the
expected outcome, they help us see the big picture when we look at the list of tests
in our IDE’s “outline view” (see Figure 24.2). This satisfi es our need for Tests as
Documentation (see page 23).
Testcase Class per Feature
Testcase
Class per
Feature
630
Chapter 24 Test Organization Patterns
Figure 24.2 Testcase Class per Feature example as seen in the Package Explorer
of the Eclipse IDE. Note how we do not need to include the starting state in the
Test Method names, leaving room for the name of the method being called and
the expected end state.
Testcase
Class per
Feature
631
Testcase Class per Fixture
How do we organize our Test Methods onto Testcase Classes?
We organize Test Methods into Testcase Classes based on commonality
of the test fi xture.
As the number of Test Methods (page 348) grows, we need to decide on which
Testcase Class (page 373) to put each Test Method. Our choice of a test organi-
zation strategy affects how easily we can get a “big picture” view of our tests. It
also affects our choice of a fi xture setup strategy.
Using a Testcase Class per Fixture lets us take advantage of the Implicit
Setup (page 424) mechanism provided by the Test Automation Framework
(page 298).
How It Works
We group our Test Methods onto Testcase Classes based on which test fi xture
they require as a starting point. This organization allows us to use Implicit
Setup to move the entire fi xture setup logic into the setUp method, thereby allow-
ing each test method to focus on the exercise SUT and verify outcome phases of
the Four-Phase Test (page 358).
Fixture B
Fixture A
SUT Class
FixtureBTestcaseClass
testMethod_1
testMethod_2
FixtureATestcaseClass
testMethod_2
setUp
setUp
feature_1
feature_2
Creation
Creation
Exercise
Exercise
FixtureATestcaseClass
testMethod_1
Fixture B
Fixture A
SUT Class
FixtureBTestcaseClass
testMethod_1
testMethod_2
FixtureATestcaseClass
testMethod_2
setUp
setUp
feature_1
feature_2
Creation
Creation
Exercise
Exercise
FixtureATestcaseClass
testMethod_1
Testcase Class per Fixture
Testcase
Class per
Fixture
632
Chapter 24 Test Organization Patterns
When to Use It
We can use the Testcase Class per Fixture pattern whenever we have a group of
Test Methods that need an identical fi xture and we want to make each test method
as simple as possible. If each test needs a unique fi xture, using Testcase Class per
Fixture doesn’t make a lot of sense because we will end up with a large number
of single-test classes; in such a case, it would be better to use either Testcase
Class per Feature (page 624) or simply Testcase Class per Class (page 617).
One benefi t of Testcase Class per Fixture is that we can easily see whether we
are testing all the operations from each starting state. We should end up with
the same lineup of test methods on each Testcase Class, which is very easy to see
in an “outline view” or “method browser” of an IDE. This attribute makes the
Testcase Class per Fixture pattern particularly useful for discovering Missing Unit
Tests (see Production Bugs on page 268) long before we go into production.
Testcase Class per Fixture is a key part of the behavior-driven development style
of testing/specifi cation. It leads to very short test methods, often featuring only a
single assertion per test method. When combined with a test method naming con-
vention that summarizes the expected outcome of the test, this pattern leads to
Tests as Documentation (see page 23).
Implementation Notes
Because we set up the fi xture in a method called by the Test Automation Frame-
work (the setUp method), we must use an instance variable to hold a reference to
the fi xture we created. In such a case, we must be careful not to use a class vari-
able, as it can lead to a Shared Fixture (page 317) and the Erratic Tests (page 228)
that often accompany this kind of fi xture. [The sidebar “There’s Always an
Exception” on page 384 lists xUnit members that don’t guarantee Independent
Tests (see page 42) when we use instance variables.]
Because each Testcase Class represents a single test fi xture confi guration, it
makes sense to name the Testcase Class based on the fi xture it creates. Similarly,
we can name each test method based on the method of the SUT being exercised,
the characteristics of any arguments passed to the SUT method, and the expected
outcome of that method call.
One side effect of using Testcase Class per Fixture is that we end up with
a larger number of Testcase Classes. We may want to fi nd a way to group the
various Testcase Classes that verify a single SUT class. One way to do so is to
create a nested folder, package, or namespace to hold just these test classes. If
we are using Test Enumeration (page 399), we’ll also want to create an AllTests
Testcase
Class per
Fixture
633
Suite (see Named Test Suite on page 592) to aggregate all the Testcase Class per
Fixtures into a single suite.
Another side effect is that the tests for a single feature of the SUT are spread
across several Testcase Classes. This distribution may be a good thing if the
features are closely related to one another because it highlights their interdepen-
dency. Conversely, if the features are somewhat unrelated, their dispersal may
be disconcerting. In such a case, we can either refactor to use Testcase Class per
Feature or apply an Extract Class [Fowler] refactoring on the SUT if we decide
that this symptom indicates that the class has too many responsibilities.
Motivating Example
The following example uses Testcase Class per Class to structure the Test Methods
for a Flight class that has three states (Unscheduled, Scheduled, and AwaitingApproval)
and four methods (schedule, requestApproval, deSchedule, and approve). Because the
class is stateful, we need at least one test for each state for each method. (In the
interest of saving trees, I’ve omitted many of the method bodies; please refer to
Testcase Class per Class for the full listing.)
public class FlightStateTest extends TestCase {
public void testRequestApproval_FromScheduledState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInScheduledState();
try {
flight.requestApproval();
fail("not allowed in scheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"requestApproval",
e.getRequest());
assertTrue("isScheduled()", flight.isScheduled());
}
}
public void testRequestApproval_FromUnsheduledState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInUnscheduledState();
flight.requestApproval();
assertTrue("isAwaitingApproval()",
flight.isAwaitingApproval());
}
public void testRequestApproval_FromAwaitingApprovalState()
throws Exception {
Testcase Class per Fixture
Testcase
Class per
Fixture
634
Chapter 24 Test Organization Patterns
Flight flight = FlightTestHelper.
getAnonymousFlightInAwaitingApprovalState();
try {
flight.requestApproval();
fail("not allowed in awaitingApproval state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"requestApproval",
e.getRequest());
assertTrue("isAwaitingApproval()",
flight.isAwaitingApproval());
}
}
public void testSchedule_FromUnscheduledState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInUnscheduledState();
flight.schedule();
assertTrue( "isScheduled()", flight.isScheduled());
}
public void testSchedule_FromScheduledState()
throws Exception {
// I've omitted the bodies of the rest of the tests to
// save a few trees
}
}
This example uses Delegated Setup (page 411) of a Fresh Fixture (page 311)
to achieve a more declarative style of fi xture construction. Even so, this class is
getting rather large and keeping track of the Test Methods is becoming a bit of a
chore. Because the Test Methods on this Testcase Class require three distinct test
fi xtures (one for each state the fl ight can be in), it is a good example of a test that
can be improved through refactoring to Testcase Class per Fixture.
Refactoring Notes
We can remove Test Code Duplication (page 213) in the fi xture setup and make
the Test Methods easier to understand by converting them to use the Testcase
Class per Fixture pattern. First, we determine how many classes we want to cre-
ate and which Test Methods should go into each one. If some Testcase Classes
will end up being smaller than others, it will reduce our work if we start with
the smaller ones. Next, we do an Extract Class refactoring to create one of the
Testcase Classes and give it a name that describes the fi xture it requires. Then,
we do a Move Method [Fowler] refactoring on each Test Method that belongs
in this new class, along with any instance variables it uses.
Testcase
Class per
Fixture
635
We repeat this process until we are down to just one fi xture in the original
class; we can then rename that class based on the fi xture it creates. At this point,
each of the Testcase Classes should compile and run—but we still aren’t com-
pletely done. To get the full benefi t of the Testcase Class per Fixture pattern,
we have two more steps to complete. First, we should factor out any common
fi xture setup logic from each of the Test Methods into the setUp method, result-
ing in an Implicit Setup. This type of setup is made possible because the Test
Methods on each class have the same fi xture requirements. Second, we should
do a Rename Method [Fowler] refactoring on each of the Test Methods to bet-
ter refl ect what the Test Method is verifying. We can remove any mention of the
starting state from each Test Method name, because that information should
be captured in the name of the Testcase Class. This refactoring leaves us with
“room” to include both the action (the method being called plus the nature of
the arguments) and the expected result in the method name.
As described in Testcase Class per Fixture, we can also refactor to this pat-
tern by making one copy of the Testcase Class (suitably named) for each fi xture,
deleting the unnecessary Test Methods from each one, and fi nally deleting the
old Testcase Class.
Example: Testcase Class per Fixture
In this example, the earlier set of tests has been converted to use the Testcase
Class per Fixture pattern. (In the interest of saving trees, I’ve shown only one of
the resulting Testcase Classes; the others look pretty similar.)
public class TestScheduledFlight extends TestCase {
Flight scheduledFlight;
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());
}
Testcase Class per Fixture
Testcase
Class per
Fixture
636
Chapter 24 Test Organization Patterns
public void testRequestApproval_shouldThrowInvalidRequestEx(){
try {
scheduledFlight.requestApproval();
fail("not allowed in scheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"requestApproval", e.getRequest());
assertTrue("isScheduled()",
scheduledFlight.isScheduled());
}
}
public void testSchedule_shouldThrowInvalidRequestEx() {
try {
scheduledFlight.schedule();
fail("not allowed in scheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"schedule", e.getRequest());
assertTrue("isScheduled()",
scheduledFlight.isScheduled());
}
}
public void testApprove_shouldThrowInvalidRequestEx()
throws Exception {
try {
scheduledFlight.approve("Fred");
fail("not allowed in scheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"approve", e.getRequest());
assertTrue("isScheduled()",
scheduledFlight.isScheduled());
}
}
}
Note how much simpler each Test Method has become! Because we have used
Intent-Revealing Names [SBPP] for each of the Test Methods, we can use the
Tests as Documentation. By looking at the list of methods in the “outline view”
of our IDE, we can see the starting state (fi xture), the action (method being
called), and the expected outcome (what it returns or the post-test state)—all
without even opening up the method body (Figure 24.3).
Testcase
Class per
Fixture
637
Figure 24.3 The tests for our Testcase Class per Fixture as seen in the Package
Explorer of the Eclipse IDE. Note how we do not need to include the name of
the method being called in the Test Method names, leaving room for the starting
state and the expected end state.
This “big picture” view of our tests makes it clear that we are only testing
the approve method arguments when the Flight is in the awaitingApproval state. We
can now decide whether that limitation is a shortcoming of the tests or part of
the specifi cation (i.e., the result of calling approve is “undefi ned” for some states
of the Flight).
Testcase Class per Fixture
Testcase
Class per
Fixture