Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
418
with the problem of how to set up the starting state in each test without a lot of
Test Code Duplication (page 213).
One obvious solution is to put all tests that depend on the same starting state
into the same Testcase Class (page 373) and to create the SUT in the appropri-
ate state in the setUp method using Implicit Setup (page 424) (called Testcase
Class per Fixture; see page 631). The alternative is to use Delegated Setup by
calling a Named State Reaching Method; this approach allows us to choose
some other way to organize our Testcase Classes.
Either way, the code that sets up the SUT will be easier to understand if it
is short and sweet. That’s where a Named State Reaching Method comes in
handy. By encapsulating the logic required to create the test objects in the cor-
rect state in a single place (whether on the Testcase Class or a Test Helper), we
reduce the amount of code we must update if we need to change how we put
the test object into that state.
Variation: Attachment Method
Suppose we already have a test object and we want to modify it in some way. We
fi nd ourselves performing this task in enough tests to want to code this modifi ca-
tion once and only once. The solution in this case is an Attachment Method. The
main difference between this variation and the original Creation Method pattern
is that we pass in the object to be modifi ed (one that was probably returned by
another Creation Method) and the object we want to set one of its attributes to;
the Attachment Method does the rest of the work for us.
Implementation Notes
Most Creation Methods are created by doing an Extract Method [Fowler] refac-
toring on parts of an existing test. When we write tests in an “outside-in” man-
ner, we assume that the Creation Methods already exist and fi ll in the method
bodies later. In effect, we defi ne a Higher-Level Language (see page 41) for defi n-
ing our fi xtures. Nevertheless, there is another, completely different way to defi ne
Creation Methods.
Variation: Reuse Test for Fixture Setup
We can set up the fi xture by calling another Test Method to do the fi xture setup
for us. This assumes that we have some way of accessing the fi xture that the
other test created, either through a Registry [PEAA] object or through instance
variables of the Testcase Object (page 382).
It may be appropriate to implement a Creation Method in this way when
we already have tests that depend on other tests to set up their test fi xture but
Creation
Method
Chapter 20 Fixture Setup Patterns
419
we want to reduce the likelihood that a change in the test execution order of
Chained Tests (page 454) will cause tests to fail. Mind you, the tests will run
more slowly because each test will call all the preceding tests it depends on each
time each test is run rather than each test being run only once per test run. Of
course, each test needs to call only the specifi c tests it actually depends on, not all
tests in the test suite. This slowdown won’t be very noticeable if we have replaced
any slow components, such as a database, with a Fake Object (page 551).
Wrapping the Test Method in a Creation Method is a better option than
calling the Test Method directly from the client Test Method because most Test
Methods are named based on which test condition(s) they verify, not what (fi x-
ture) they leave behind. The Creation Method lets us put a nice Intent-Revealing
Name between the client Test Method and the implementing Test Method. It
also solves the Lonely Test (see Erratic Test) problem because the other test is
run explicitly from within the calling test rather than just assuming that it was
already run. This scheme makes the test less fragile and easier to understand but
it won’t solve the Interacting Tests (see Erratic Test) problem: If the test we call
fails and leaves the test fi xture in a different state than we expected, our test will
likely fail as well, even if the functionality we are testing is still working.
Motivating Example
In the following example, the testPurchase test requires a Customer to fi ll the role of
the buyer. The fi rst and last names of the buyer have no bearing on the act of pur-
chasing, but are required parameters of the Customer constructor; we do care that
the Customer’s credit rating is good (“G”) and that he or she is currently active.
public void testPurchase_firstPurchase_ICC() {
Customer buyer =
new Customer(17, "FirstName", "LastName", "G","ACTIVE");
// ...
}
public void testPurchase_subsequentPurchase_ICC() {
Customer buyer =
new Customer(18, "FirstName", "LastName", "G","ACTIVE");
// ...
}
The use of constructors in tests can be problematic, especially when we are
building an application incrementally. Every change to the parameters of the
constructor will force us to revisit a lot of tests or jump through hoops to keep
the constructor signatures backward compatible for the sake of the tests.
Creation
Method
Creation Method
420
Refactoring Notes
We can use an Extract Method refactoring to remove the direct call to the construc-
tor. We can give the new Creation Method an appropriate Intent-Revealing Name
such as createCustomer based on the style of Creation Method we have created.
Example: Anonymous Creation Method
In the following example, instead of making that direct call to the Customer
constructor, we now use the Customer Creation Method. Notice that the coupling
between the fi xture setup code and the constructor has been removed. If another
parameter such as phone number is added to the Customer constructor, only the
Customer Creation Method must be updated to provide a default value; the fi xture
setup code remains insulated from the change thanks to encapsulation.
public void testPurchase_firstPurchase_ACM() {
Customer buyer = createAnonymousCustomer();
// ...
}
public void testPurchase_subsequentPurchase_ACM() {
Customer buyer = createAnonymousCustomer();
// ...
}
We call this pattern an Anonymous Creation Method because the identity of
the customer does not matter. The Anonymous Creation Method might look
something like this:
public Customer createAnonymousCustomer() {
int uniqueid = getUniqueCustomerId();
return new Customer(uniqueid,
"FirstName" + uniqueid,
"LastName" + uniqueid,
"G", "ACTIVE");
}
Note the use of a Distinct Generated Value to ensure that each anonymous Customer
is slightly different to avoid accidentally creating an identical Customer.
Example: Parameterized Creation Method
If we wanted to supply some of the Customer’s attributes as parameters, we could
defi ne a Parameterized Creation Method:
public void testPurchase_firstPurchase_PCM() {
Customer buyer =
createCreditworthyCustomer("FirstName", "LastName");
Creation
Method
Chapter 20 Fixture Setup Patterns
421
// ...
}
public void testPurchase_subsequentPurchase_PCM() {
Customer buyer = createCreditworthyCustomer("FirstName", "LastName");
// ...
}
Here’s the corresponding Parameterized Creation Method defi nition:
public Customer createCreditworthyCustomer(
String firstName, String lastName) {
int uniqueid = getUniqueCustomerId();
Customer customer =
new Customer(uniqueid,firstName,lastName,"G","ACTIVE");
customer.setCredit(CreditRating.EXCELLENT);
customer.approveCredit();
return customer;
}
Example: Attachment Method
Here’s an example of a test that uses an Attachment Method to associate two
customers to verify that both get the best discount either of them has earned or
negotiated:
public void testPurchase_relatedCustomerDiscount_AM() {
Customer buyer = createCreditworthyCustomer("Related", "Buyer");
Customer discountHolder =
createCreditworthyCustomer("Discount", "Holder");
createRelationshipBetweenCustomers( buyer, discountHolder);
// ...
}
Behind the scenes, the Attachment Method does whatever it takes to establish
the relationship:
private void createRelationshipBetweenCustomers(
Customer buyer,
Customer discountHolder) {
buyer.addToRelatedCustomersList( discountHolder );
discountHolder.addToRelatedCustomersList( buyer );
}
Although this example is relatively simple, the call to this method is still easier to
understand than reading both the method calls of which it consists.
Creation
Method
Creation Method
422
Example: Test Reused for Fixture Setup
We can reuse other tests to set up the fi xture for our test. Here is an example of
how not to do it:
private Customer buyer;
private AccountManager sut = new AccountManager();
private Account account;
public void testCustomerConstructor_SRT() {
// Exercise
buyer = new Customer(17, "First", "Last", "G", "ACTIVE");
// Verify
assertEquals( "First", buyer.firstName(), "first");
// ...
}
public void testPurchase_SRT() {
testCustomerConstructor_SRT(); // Leaves in field "buyer"
account = sut.createAccountForCustomer( buyer );
assertEquals( buyer.name, account.customerName, "cust");
// ...
}
The problem here is twofold. First, the name of the Test Method we are calling
describes what it verifi es (e.g., a name) and not what it leaves behind (i.e., a Customer
in the buyer fi eld. Second, the test does not return a Customer; it leaves the Customer in
an instance variable. This scheme works only because the Test Method we want
to reuse is on the same Testcase Class; if it were on an unrelated class, we would
have to do a few backfl ips to access the buyer. A better way to accomplish this goal
is to encapsulate this call behind a Creation Method:
private Customer buyer;
private AccountManager sut = new AccountManager();
private Account account;
public void testCustomerConstructor_RTCM() {
// Exercise
buyer = new Customer(17, "First", "Last", "G", "ACTIVE");
// Verify
assertEquals( "First", buyer.firstName(), "first");
// ...
}
public void testPurchase_RTCM() {
buyer = createCreditworthyCustomer();
account = sut.createAccountForCustomer( buyer );
assertEquals( buyer.name, account.customerName, "cust");
// ...
}
public Customer createCreditworthyCustomer() {
testCustomerConstructor_RTCM();
Creation
Method
Chapter 20 Fixture Setup Patterns
423
return buyer;
// ...
}
Notice how much more readable this test has become? We can see where the buyer
came from! This was easy to do because both Test Methods were on the same
class. If they were on different classes, our Creation Method would have to create
an instance of the other Testcase Class before it could run the test. Then it would
have to fi nd a way to access the buyer instance variable so that it could return it
to the calling Test Method.
Creation
Method
Creation Method
424
Implicit Setup
How do we construct the Fresh Fixture?
We build the test fi xture common to several tests in the setUp method.
To execute an automated test, we require a text fi xture that is well understood
and completely deterministic. We are using a Fresh Fixture (page 311) approach
to build the Minimal Fixture (page 302) for the use of this one test.
Implicit Setup is a way to reuse the fi xture setup code for all Test Meth-
ods (page 348) in a Testcase Class (page 373).
How It Works
All tests in a Testcase Class create identical Fresh Fixtures by doing test fi xture
setup in a special setUp method on the Testcase Class. The setUp method is called
automatically by the Test Automation Framework (page 298) before it calls each
Test Method. This allows the fi xture setup code placed in the setUp method to
be reused without reusing the same instance of the test fi xture. This approach is
called “implicit” setup because the calls to the fi xture setup logic are not explicit
within the Test Method, unlike with In-line Setup (page 408) and Delegated Set-
up (page 411).
Fixture
SUT
Testcase Class
setup
test_1
test_2
test_n
Setup
Fixture
SUT
Testcase Class
setup
test_1
test_2
test_n
Setup
Also known as:
Hooked Setup,
Framework-
Invoked Setup,
Shared Setup
Method
Implicit
Setup
Chapter 20 Fixture Setup Patterns
425
When to Use It
We can use Implicit Setup when several Test Methods on the same Testcase Class
need an identical Fresh Fixture. If all Test Methods need the exact same fi xture,
then the entire Minimal Fixture needed by each test can be set up in the setUp
method. This form of Test Method organization is known as Testcase Class per
Fixture (page 631).
When the Test Methods need different fi xtures because we are using a Testcase
Class per Feature (page 624) or Testcase Class per Class (page 617) scheme, it
is more diffi cult to use Implicit Setup and still build a Minimal Fixture. We can
use the setUp method only to set up the part of the fi xture that does not cause any
problems for the other tests. A reasonable compromise is to use Implicit Setup to
set up the parts of the fi xture that are essential but irrelevant and leave the setup
of critical (and different from test to test) parts of the fi xture to the individual
Test Methods. Examples of “essential but irrelevant” fi xture setup include ini-
tializing variables with “don’t care” values and initializing hidden “plumbing”
such as database connections. Fixture setup logic that directly affects the state of
the SUT should be left to the individual Test Methods unless every Test Method
requires the same starting state.
The obvious alternatives for creating a Fresh Fixture are In-line Setup, in
which we include all setup logic within each Test Method without factoring out
any common code, and Delegated Setup, in which we move all common fi xture
setup code into a set of Creation Methods (page 415) that we can call from
within the setup part of each Test Method.
Implicit Setup removes a lot of Test Code Duplication (page 213) and helps
prevent Fragile Tests (page 239) by moving much of the nonessential interaction
with the SUT out of the very numerous tests and into a much smaller num-
ber of places where it is easier to maintain. It can, however, lead to Obscure
Tests (page 186) when a Mystery Guest makes the test fi xture used by each test
less obvious. It can also lead to a Fragile Fixture (see Fragile Test) if all tests in
the class do not really need identical test fi xtures.
Implementation Notes
The main implementation considerations for Implicit Setup are as follows:
• How do we cause the fi xture setUp method to be called?
• How do we tear the fi xture down?
• How do the Test Methods access the fi xture?
Implicit Setup
Implicit
Setup
426
Calling the Setup Code
A setUp method is the most common way to handle Implicit Setup; it consists of
having the Test Automation Framework call the
setUp method before each Test
Method. Strictly speaking, the
setUp method is not the only form of implicit fi x-
ture setup. Suite Fixture Setup (page 441), for example, is used to set up and tear
down a Shared Fixture (page 317) that is reused by the Test Methods on a single
Testcase Class. In addition, Setup Decorator (page 447) moves the setUp method
to a Decorator [GOF] object installed between the Test Suite Object (page 387)
and the Test Runner (page 377). Both are forms of Implicit Setup because the
setUp logic is not explicit within the Test Method.
Tearing Down the Fixture
The fi xture teardown counterpart of Implicit Setup is Implicit Teardown (page 516).
Anything that we set up in the setUp method that is not automatically cleaned up by
Automated Teardown (page 503) or garbage collection should be torn down in the
corresponding tearDown method.
Accessing the Fixture
The Test Methods need to be able to access the test fi xture built in the
setUp method. When they were used in the same method, local variables were
suffi cient. To communicate between the setUp method and the Test Method, how-
ever, the local variables must be changed into instance variables. We must be
careful not to make them class variables as this will result in the potential for a
Shared Fixture. (See the sidebar “There’s Always an Exception” on page 384 for a
description of when instance variations do not provide this level of isolation.)
Motivating Example
In the following example, each test needs to create a fl ight between a pair of
airports.
public void testStatus_initial() {
// in-line setup
Airport departureAirport = new Airport("Calgary", "YYC");
Airport destinationAirport = new Airport("Toronto", "YYZ");
Flight flight = new Flight( flightNumber,
departureAirport,
destinationAirport);
// exercise SUT and verify outcome
assertEquals(FlightState.PROPOSED, flight.getStatus());
// teardown
// garbage-collected
Implicit
Setup
Chapter 20 Fixture Setup Patterns
427
}
public void testStatus_cancelled() {
// in-line setup
Airport departureAirport = new Airport("Calgary", "YYC");
Airport destinationAirport = new Airport("Toronto", "YYZ");
Flight flight = new Flight( flightNumber,
departureAirport,
destinationAirport);
flight.cancel(); // still part of setup
// exercise SUT and verify outcome
assertEquals(FlightState.CANCELLED, flight.getStatus());
// teardown
// garbage-collected
}
Refactoring Notes
These tests contain a fair amount of Test Code Duplication. We can remove this
duplication by refactoring this Testcase Class to use Implicit Setup. There are
two refactoring cases to consider.
First, when we discover that all tests are doing similar work to set up their
test fi xtures but are not sharing a setUp method, we can do an Extract Meth-
od [Fowler] refactoring of the fi xture setup logic in one of the tests to create
our setUp method. We will also need to convert any local variables to instance
variables (fi elds) that hold the references to the resulting fi xture until the Test
Method can access it.
Second, when we discover that a Testcase Class already uses the setUp method to
build the fi xture and has tests that need a different fi xture, we can use an Extract
Class [Fowler] refactoring to move all Test Methods that need a different setup
method to a different class. We need to ensure any instance variables that are used
to convey knowledge of the fi xture from the setup method to the Test Methods
are transferred along with the setUp method. Sometimes it is simpler to clone the
Testcase Class and delete each test from one or the other copy of the class; we can
then delete from each class any instance variables that are no longer being used.
Example: Implicit Setup
In this modifi ed example, we have moved all common fi xture setup code to the
setUp method of our Testcase Class. This avoids the need to repeat this code in
each test and makes each test much shorter—which is a good thing.
Airport departureAirport;
Airport destinationAirport;
Implicit
Setup
Implicit Setup