Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
618
Chapter 24 Test Organization Patterns
When to Use It
Using a Testcase Class per Class is a good starting point when we don’t have very
many Test Methods or we are just starting to write tests for our SUT. As the number
of tests increases and we gain a better understanding of our test fi xture require-
ments, we may want to split the Testcase Class into multiple classes. This choice
will result in either Testcase Class per Fixture (page 631; if we have a small number
of frequently used starting points for our tests) or Testcase Class per Feature
(page 624; if we have several distinct features to test). As Kent Beck would say,
“Let the code tell you what to do!”
Implementation Notes
Choosing a name for the Testcase Class is pretty simple: Just use the SUT class-
name, possibly prefi xed or suffi xed with “Test.” The method names should try
to capture at least the starting state (fi xture) and the feature (method) being
exercised, along with a summary of the parameters to be passed to the SUT. Given
these requirements, we likely won’t have “room” for the expected outcome in the
method name, so the test reader must look at the Test Method body to determine
the expected outcome.
The creation of the fi xture is the primary implementation concern when using
a Testcase Class per Class. Confl icting fi xture requirements will inevitably arise
among the various Test Methods, which makes use of Implicit Setup (page 424)
diffi cult and forces us to use either In-line Setup (page 408) or Delegated Set-
up (page 411). A second consideration is how to make the nature of the fi x-
ture visible within each test method so as to avoid Obscure Tests (page 186).
Delegated Setup (using Creation Methods; see page 415) tends to lead to more
readable tests unless the In-line Setup is very simple.
Example: Testcase Class per Class
Here’s an example of using the Testcase Class per Class pattern 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.
public class FlightStateTest extends TestCase {
public void testRequestApproval_FromScheduledState() throws Exception {
Flight flight = FlightTestHelper.getAnonymousFlightInScheduledState();
Testcase
Class per
Class
619
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 {
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 {
Flight flight = FlightTestHelper.
getAnonymousFlightInScheduledState();
try {
flight.schedule();
fail("not allowed in scheduled state");
Testcase Class per Class
Testcase
Class per
Class
620
Chapter 24 Test Organization Patterns
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"schedule",
e.getRequest());
assertTrue("isScheduled()", flight.isScheduled());
}
}
public void testSchedule_FromAwaitingApprovalState()
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());
}
}
public void testDeschedule_FromScheduledState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInScheduledState();
flight.deschedule();
assertTrue("isUnscheduled()", flight.isUnscheduled());
}
public void testDeschedule_FromUnscheduledState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInUnscheduledState();
try {
flight.deschedule();
fail("not allowed in unscheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"deschedule",
e.getRequest());
assertTrue("isUnscheduled()", flight.isUnscheduled());
}
}
public void testDeschedule_FromAwaitingApprovalState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInAwaitingApprovalState();
try {
Testcase
Class per
Class
621
flight.deschedule();
fail("not allowed in awaitingApproval state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"deschedule",
e.getRequest());
assertTrue( "isAwaitingApproval()",
flight.isAwaitingApproval());
}
}
public void testApprove_FromScheduledState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInScheduledState();
try {
flight.approve("Fred");
fail("not allowed in scheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"approve",
e.getRequest());
assertTrue("isScheduled()", flight.isScheduled());
}
}
public void testApprove_FromUnsheduledState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInUnscheduledState();
try {
flight.approve("Fred");
fail("not allowed in unscheduled state");
} catch (InvalidRequestException e) {
assertEquals("InvalidRequestException.getRequest()",
"approve",
e.getRequest());
assertTrue( "isUnscheduled()", flight.isUnscheduled());
}
}
public void testApprove_FromAwaitingApprovalState()
throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInAwaitingApprovalState();
flight.approve("Fred");
assertTrue("isScheduled()", flight.isScheduled());
}
public void testApprove_NullArgument() throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInAwaitingApprovalState();
Testcase Class per Class
Testcase
Class per
Class
622
Chapter 24 Test Organization Patterns
try {
flight.approve(null);
fail("Failed to catch no approver");
} catch (InvalidArgumentException e) {
assertEquals("e.getArgumentName()",
"approverName", e.getArgumentName());
assertNull( "e.getArgumentValue()",
e.getArgumentValue());
assertTrue( "isAwaitingApproval()",
flight.isAwaitingApproval());
}
}
public void testApprove_InvalidApprover() throws Exception {
Flight flight = FlightTestHelper.
getAnonymousFlightInAwaitingApprovalState();
try {
flight.approve("John");
fail("Failed to validate approver");
} catch (InvalidArgumentException e) {
assertEquals("e.getArgumentName()",
"approverName",
e.getArgumentName());
assertEquals("e.getArgumentValue()",
"John",
e.getArgumentValue());
assertTrue( "isAwaitingApproval()",
flight.isAwaitingApproval());
}
}
}
This example uses Delegated Setup 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. Even
the “big picture” provided by our IDE is not that illuminating; we can see the test
conditions being exercised but cannot tell what the expected outcome should be
without looking at the method bodies (Figure 24.1).
Testcase
Class per
Class
623
Figure 24.1 Testcase Class per Class example as seen in the Package Explorer
of the Eclipse IDE. Note how both the starting state and event are included in
the Test Method names.
Testcase Class per Class
Testcase
Class per
Class
624
Chapter 24 Test Organization Patterns
Testcase Class per Feature
How do we organize our Test Methods onto Testcase Classes?
We group the Test Methods onto Testcase Classes based on which testable
feature of the SUT they exercise.
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 Feature gives us a systematic way to break up a
large Testcase Class into several smaller ones without having to change our Test
Methods.
How It Works
We group our Test Methods onto Testcase Classes based on which feature of the
Testcase Class they verify. This organizational scheme allows us to have smaller
Testcase Classes and to see at a glance all the test conditions for a particular
feature of the class.
Fixture B
Fixture A
SUT Class
Feature2TestcaseClass
testMethod_A
Outputs)
testMethod_B
Feature1TestcaseClass
testMethod_A
testMethod_B
Creation
feature_1
feature_2
Creation
Exercise
Exercise
Fixture B
Fixture A
SUT Class
Feature2TestcaseClass
testMethod_A
Outputs)
testMethod_B
Feature1TestcaseClass
testMethod_A
testMethod_B
Creation
feature_1
feature_2
Creation
Exercise
Exercise
Testcase
Class per
Feature
625
When to Use It
We can use a Testcase Class per Feature when we have a signifi cant number of Test
Methods and we want to make the specifi cation of each feature of the SUT more
obvious. Unfortunately, Testcase Class per Feature does not make each individual
Test Method any simpler or easier to understand; only Testcase Class per Fixture
(page 631) helps on that front. Likewise, it doesn’t make much sense to use
Testcase Class per Feature when each feature of the SUT requires only one or two
tests; in that case, we can stick with a single Testcase Class per Class (page 617).
Note that having a large number of features on a class is a “smell” indicating
the possibility that the class might have too many responsibilities. We typically
use Testcase Class per Feature when we are writing customer tests for methods
on a service Facade [GOF].
Variation: Testcase Class per Method
When a class has methods that take a lot of different parameters, we may have
many tests for the one method. We can group all of these Test Methods onto a
single Testcase Class per Method and put the rest of the Test Methods onto one
or more other Testcase Classes.
Variation: Testcase Class per Feature
Although a “feature” of a class is typically a single operation or function, it may
also be a set of related methods that operate on the same instance variable of
the object. For example, the set and get methods of a Java Bean would be con-
sidered a single (and trivial) “feature” of the class that contains those methods.
Similarly, a Data Access Object [CJ2EEP] would provide methods to both read
and write objects. It is diffi cult to test these methods in isolation, so we can treat
the reading and writing of one kind of object as a feature.
Variation: Testcase Class per User Story
If we are doing highly incremental development (such as we might do with eXtreme
Programming), it can be useful to put the new Test Methods for each story into a
different Testcase Class. This practice prevents commit-related confl icts when dif-
ferent people are working on different stories that affect the same SUT class. The
Testcase Class per User Story pattern may or may not end up being the same as
Testcase Class per Feature or Testcase Class per Method, depending on how we
partition our user stories.
Testcase Class per Feature
Testcase
Class per
Feature
626
Chapter 24 Test Organization Patterns
Implementation Notes
Because each Testcase Class represents the requirements for a single feature of
the SUT, it makes sense to name the Testcase Class based on the feature it veri-
fi es. Similarly, we can name each test method based on which test condition of
the SUT is being verifi ed. This nomenclature allows us to see all the test condi-
tions at a glance by merely looking at the names of the Test Methods of the
Testcase Class.
One consequence of using Testcase Class per Feature is that we end up with
a larger number of Testcase Classes for a single production class. Because we
still want to run all the tests for this class, we should put these Testcase Classes
into a single nested folder, package, or namespace. We can use an AllTests Suite
(see Named Test Suite on page 592) to aggregate all of the Testcase Classes into
a single test suite if we are using Test Enumeration (page 399).
Motivating Example
This example uses the Testcase Class per Class pattern to structure the Test
Methods for a Flight class that has three states (Unscheduled, Scheduled, and Await-
ingApproval
) 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();
Testcase
Class per
Feature
627
flight.requestApproval();
assertTrue("isAwaitingApproval()",
flight.isAwaitingApproval());
}
public void testRequestApproval_FromAwaitingApprovalState()
throws Exception {
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 four distinct
methods, it is a good example of a test that can be improved through refactoring
to Testcase Class per Feature.
Refactoring Notes
We can reduce the size of each Testcase Class and make the names of the Test
Methods more meaningful by converting them to follow the Testcase Class per
Feature pattern. First, we determine how many classes we want to create and
Testcase Class per Feature
Testcase
Class per
Feature