Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
598
Chapter 24 Test Organization Patterns
public class SmokeTestSuite extends TestCase {
public static Test suite() {
TestSuite mySuite = new TestSuite("Smoke Tests");
mySuite.addTest( new LostTests("testSeventeen") );
mySuite.addTest( new SampleTests("testOne") );
mySuite.addTest( new FlightManagementFacadeTest(
"testGetFlightsByOriginAirports_TwoOutboundFlights"));
// add additional tests here as needed...
return mySuite;
}
}
This scheme won’t test our system thoroughly, but it is a quick way to fi nd out
whether some part of the core functionality is broken.
Named Test
Suite
599
Test Utility Method
How do we reduce Test Code Duplication?
We encapsulate the test logic we want to reuse behind a suitably
named utility method.
As we write tests, we will invariably fi nd ourselves needing to repeat the same
logic in many, many tests. Initially, we will just “clone and twiddle” as we write
additional tests that need the same logic. Sooner or later, however, we will come to
the realization that this Test Code Duplication (page 213) is starting to cause prob-
lems. This point is a good time to think about introducing a Test Utility Method.
How It Works
The subroutine and the function were two of the earliest ways devised to reuse
logic in several places within a program. A Test Utility Method is just the same
principle applied to object-oriented test code. We move any logic that appears
in more than one test into a Test Utility Method; we can then call this method
from various tests or even several times from within a single test. Of course, we
will want to pass in anything that varies from usage to usage as arguments to
the Test Utility Method.
Test Utility
Methods
Setup
Exercise
Verify
Teardown
SUT
Creation
Method
Cleanup
Method
Fixture
Encapsulation
Method
SUT
Finder
Method
Verification
Method
Custom
Assertion
Test Utility
Methods
Setup
Exercise
Verify
Teardown
SUT
Creation
Method
Cleanup
Method
Fixture
Encapsulation
Method
SUT
Finder
Method
Verification
Method
Custom
Assertion
Test Utility Method
Test Utility
Method
600
Chapter 24 Test Organization Patterns
When to Use It
We should use a Test Utility Method whenever test logic appears in several tests
and we want to be able to reuse that logic. We might also use a Test Utility Method
because we want to be very sure that the logic works as expected. The best way
to achieve that kind of certainty is to write Self-Checking Tests (unit tests—see
page 26) for the reusable test logic. Because the Test Methods (page 348) cannot
easily be tested, it is best to do this by moving the logic out of the test methods
and into Test Utility Methods, where it can be more easily tested.
The main drawback of using the Test Utility Method pattern is that it creates
another API that the test automaters must build and understand. This extra ef-
fort can be largely mitigated through the use of Intent-Revealing Names [SBPP]
for the Test Utility Methods and through the use of refactoring as the means for
defi ning the Test Utility Methods.
There are as many different kinds of Test Utility Methods as there are kinds
of logic in a Test Method. Next, we briefl y summarize some of the most popu-
lar kinds. Some of these variations are important enough to warrant their own
pattern write-ups in the corresponding section of this book.
Variation: Creation Method
Creation Methods (page 415) are used to create ready-to-use objects as part of
fi xture setup. They hide the complexity of object creation and interdependencies
from the test. Creation Method has enough variants to warrant addressing this
pattern in its own section.
Variation: Attachment Method
An Attachment Method (see Creation Method) is a special form of Creation
Method used to amend already-created objects as part of fi xture setup.
Variation: Finder Method
We can encapsulate any logic required to retrieve objects from a Shared Fix-
ture (page 317) within a function that returns the object(s). We then give this
function an Intent-Revealing Name so that anyone reading the test can easily
understand the fi xture we are using in this test.
We should use a Finder Method whenever we need to fi nd an existing Shared
Fixture object that meets some criteria and we want to avoid a Fragile Fixture
(see Fragile Test on page 239) and High Test Maintenance Cost (page 265).
Finder Methods can be used in either a pure Shared Fixture strategy or a
hybrid strategy such as Immutable Shared Fixture (see Shared Fixture). Finder
Test Utility
Method
601
Methods also help prevent Obscure Tests (page 186) by encapsulating
the mechanism of how the required objects are found and exactly which
objects to use, thereby enabling the reader to focus on understanding why
a particular object is being used and how it relates to the expected outcome
described in the assertions. This helps us move toward Tests as Documentation
(see page 23).
Although most Finder Methods return a single object reference, that object
may be the root of a tree of objects (e.g., an invoice might refer to the customer
and various addresses as well as containing a list of line items). In some circum-
stances, we may choose to defi ne a Finder Method that returns a collection (Array
or Hash) of objects, but the use of this type of Finder Method is less common.
Finder Methods may also update parameters to pass additional objects back to
the test that called them, although this approach is not as intent-revealing as use
of a function. I do not recommend initialization of instance variables as a way of
passing back objects because it is obscure and keeps us from moving the Finder
Method to a Test Helper (page 643) later.
The Finder Method can fi nd objects in the Shared Fixture in several ways:
by using direct references (instance variables or class variables initialized in the
fi xture setup logic), by looking the objects up using known keys, or by search-
ing for the objects using specifi c criteria. Using direct references or known keys
has the advantage of always returning exactly the same object each time the test
is run. The main drawback is that some other test may have modifi ed the object
such that it may no longer match the criteria implied by the Finder Method’s
name. Searching by criteria can avoid this problem, though the resulting tests
may take longer to run and might be less deterministic if they use different
objects each time they are run. Either way, we must modify the code in fewer
places whenever the Shared Fixture is modifi ed (compared to when the objects
are used directly within the Test Method).
Variation: SUT Encapsulation Method
Another reason for using a Test Utility Method is to encapsulate unnecessary knowl-
edge of the API of the SUT. What constitutes unnecessary? Any method we call on
the SUT that is not the method being tested creates additional coupling between
the test and the SUT. Creation Methods and Custom Assertions (page 474) are
common enough examples of SUT Encapsulation Methods to warrant their own
write-ups as separate patterns. This section focuses on the less common uses of
SUT Encapsulation Methods. For example, if the method that we are exercising
(or that we use for verifying the outcome) has a complicated signature, we
increase the amount of work involved to write and maintain the test code and may
Test Utility Method
Test Utility
Method
Also known as:
SUT API
Encapsulation
602
Chapter 24 Test Organization Patterns
make it harder to understand the tests (Obscure Test). We can avoid this problem
by wrapping these calls in SUT Encapsulation Methods that are intent-revealing
and may have simpler signatures.
Variation: Custom Assertion
Custom Assertions are used to specify test-specifi c equality in a way that is
reusable across many tests. They hide the complexity of comparing the expected
outcome with the actual outcome. Custom Assertions are typically free of side
effects in that they do not interact with the SUT to retrieve the outcome; that
task is left to the caller.
Variation: Verifi cation Method
Verifi cation Methods (see Custom Assertion) are used to verify that the expected
outcome has occurred. They hide the complexity of verifying the outcome from
the test. Unlike Custom Assertions, Verifi cation Methods interact with the SUT.
Variation: Parameterized Test
The most complete form of the Test Utility Method pattern is the Parameterized
Test (page 607). It is, in essence, an almost complete test that can be reused in
many circumstances. We simply provide the data that varies from test to test as
a parameter and let the Parameterized Test execute all the stages of the Four-
Phase Test (page 358) for us.
Variation: Cleanup Method
Cleanup Methods
1
are used during the fi xture teardown phase of the test to
clean up any resources that might still be allocated after the test ends. Refer to
the pattern Automated Teardown (page 503) for a more detailed discussion and
examples.
Implementation Notes
The main objection some people have to using Test Utility Methods is that
this pattern removes some of the logic from the test, which may make the test
harder to read. One way we can avoid this problem when using Test Utility
Methods is to give Intent-Revealing Names to the Test Utility Methods. In fact,
well-chosen names can make the tests even easier to understand because they
1
One could call this pattern a “Teardown Method,” but that name might be confused
with the method used in Implicit Teardown (page 516).
Test Utility
Method
603
help prevent Obscure Tests by defi ning a Higher Level Language (see page 41)
for defi ning tests. It is also helpful to keep the Test Utility Methods relatively
small and self-contained. We can achieve this goal by passing all arguments to
these methods explicitly as parameters (rather than using instance variables)
and by returning any objects that the tests will require as explicit return values
or updated parameters.
To ensure that the Test Utility Methods have Intent-Revealing Names, we
should let the tests pull the Test Utility Methods into existence rather than just
inventing Test Utility Methods that we think may be needed later. This “out-
side-in” approach to writing code avoids “borrowing tomorrow’s trouble” and
helps us fi nd the minimal solution.
Writing the reusable Test Utility Method is relatively straightforward. The
trickier question is where we would put this method. If the Test Utility Method
is needed only in Test Methods in a single Testcase Class (page 373), then we
can put it onto that class. If we need the Test Utility Method in several classes,
however, the solution becomes a bit more complicated. The key issue relates to
type visibility. The client classes need to be able to see the Test Utility Method,
and the Test Utility Method needs to be able to see all the types and classes
on which it depends. When it doesn’t depend on many types/classes or when
everything it depends on is visible from a single place, we can put the Test Utility
Method into a common Testcase Superclass (page 638) that we defi ne for our
project or company. If it depends on types/classes that cannot be seen from a
single place that all the clients can see, then we may need to put the Test Utility
Method on a Test Helper in the appropriate test package or subsystem. In larger
systems with many groups of domain objects, it is common practice to have one
Test Helper for each group (package) of related domain objects.
Variation: Test Utility Test
One major advantage of using Test Utility Methods is that otherwise Untestable
Test Code (see Hard-to-Test Code on page 209) can now be tested with Self-
Checking Tests. The exact nature of such tests varies based on the kind of Test
Utility Method being tested but a good example is a Custom Assertion Test (see
Custom Assertion).
Motivating Example
The following example shows a test as many novice test automaters would fi rst
write it:
public void testAddItemQuantity_severalQuantity_v1(){
Address billingAddress = null;
Test Utility Method
Test Utility
Method
604
Chapter 24 Test Organization Patterns
Address shippingAddress = null;
Customer customer = null;
Product product = null;
Invoice invoice = null;
try {
// Fixture Setup
billingAddress = new Address("1222 1st St SW",
"Calgary", "Alberta",
"T2N 2V2", "Canada");
shippingAddress = new Address("1333 1st St SW",
"Calgary", "Alberta",
"T2N 2V2", "Canada");
customer = new Customer( 99, "John", "Doe",
new BigDecimal("30"),
billingAddress,
shippingAddress);
product = new Product( 88, "SomeWidget",
new BigDecimal("19.99"));
invoice = new Invoice( customer );
// Exercise SUT
invoice.addItemQuantity( product, 5 );
// Verify Outcome
List lineItems = invoice.getLineItems();
if (lineItems.size() == 1) {
LineItem actItem = (LineItem) lineItems.get(0);
assertEquals("inv", invoice, actItem.getInv());
assertEquals("prod", product, actItem.getProd());
assertEquals("quant", 5, actItem.getQuantity());
assertEquals("discount",
new BigDecimal("30"),
actItem.getPercentDiscount());
assertEquals("unit price",
new BigDecimal("19.99"),
actItem.getUnitPrice());
assertEquals("extended",
new BigDecimal("69.96"),
actItem.getExtendedPrice());
} else {
assertTrue("Invoice should have 1 item", false);
}
} finally {
// Teardown
deleteObject(invoice);
deleteObject(product);
deleteObject(customer);
deleteObject(billingAddress);
deleteObject(shippingAddress);
}
}
This test is diffi cult to understand because it exhibits many code smells, includ-
ing Obscure Test and Hard-Coded Test Data (see Obscure Test).
Test Utility
Method
605
Refactoring Notes
We often create Test Utility Methods by mining existing tests for reusable logic
when we are writing new tests. We can use an Extract Method [Fowler] refac-
toring to pull the code for the Test Utility Method out of one Test Method
and put it onto the Testcase Class as a Test Utility Method. From there, we
may choose to move the Test Utility Method to a superclass by using a Pull
Up Method [Fowler] refactoring or to another class by using a Move Method
[Fowler] refactoring.
Example: Test Utility Method
Here’s the refactored version of the earlier test. Note how much simpler this test
is to understand than the original version. And this is just one example of what
we can achieve by using Test Utility Methods!
public void testAddItemQuantity_severalQuantity_v13(){
final int QUANTITY = 5;
final BigDecimal CUSTOMER_DISCOUNT = new BigDecimal("30");
// Fixture Setup
Customer customer =
findActiveCustomerWithDiscount(CUSTOMER_DISCOUNT);
Product product = findCurrentProductWith3DigitPrice( );
Invoice invoice = createInvoice(customer);
// Exercise SUT
invoice.addItemQuantity(product, QUANTITY);
// Verify Outcome
final BigDecimal BASE_PRICE = product.getUnitPrice().
multiply(new BigDecimal(QUANTITY));
final BigDecimal EXTENDED_PRICE =
BASE_PRICE.subtract(BASE_PRICE.multiply(
CUSTOMER_DISCOUNT.movePointLeft(2)));
LineItem expected =
createLineItem( QUANTITY, CUSTOMER_DISCOUNT,
EXTENDED_PRICE, product, invoice);
assertContainsExactlyOneLineItem(invoice, expected);
}
Let’s go through the changes step by step. First, we replaced the code to create
the Customer and the Product with calls to Finder Methods that retrieve those objects
from an Immutable Shared Fixture. We altered the code in this way because we
don’t plan to change these objects.
protected Customer findActiveCustomerWithDiscount(
BigDecimal percentDiscount) {
return CustomerHome.findCustomerById(
ACTIVE_CUSTOMER_WITH_30PC_DISCOUNT_ID);
}
Test Utility Method
Test Utility
Method
606
Chapter 24 Test Organization Patterns
Next, we introduced a Creation Method for the Invoice to which we plan to add
the LineItem.
protected Invoice createInvoice(Customer customer) {
Invoice newInvoice = new Invoice(customer);
registerTestObject(newInvoice);
return newInvoice;
}
List testObjects;
protected void registerTestObject(Object testObject) {
testObjects.add(testObject);
}
To avoid the need for In-line Teardown (page 509), we registered each of the
objects we created with our Automated Teardown mechanism, which we call
from the tearDown method.
private void deleteTestObjects() {
Iterator i = testObjects.iterator();
while (i.hasNext()) {
try {
deleteObject(i.next());
} catch (RuntimeException e) {
// Nothing to do; we just want to make sure
// we continue on to the next object in the list.
}
}
}
public void tearDown() {
deleteTestObjects();
}
Finally, we extracted a Custom Assertion to verify that the correct LineItem has
been added to the Invoice.
void assertContainsExactlyOneLineItem( Invoice invoice,
LineItem expected) {
List lineItems = invoice.getLineItems();
assertEquals("number of items", lineItems.size(), 1);
LineItem actItem = (LineItem)lineItems.get(0);
assertLineItemsEqual("",expected, actItem);
}
Test Utility
Method
607
Parameterized Test
How do we reduce Test Code Duplication when the same test
logic appears in many tests?
We pass the information needed to do fi xture setup and result verifi cation to a
utility method that implements the entire test life cycle.
Testing can be very repetitious not only because we must run the same test over
and over again, but also because many of the tests differ only slightly from
one another. For example, we might want to run essentially the same test with
slightly different system inputs and verify that the actual output varies accord-
ingly. Each of these tests would consist of the exact same steps. While having a
large number of tests is an excellent way to ensure good code coverage, it is not
so attractive from a test maintainability standpoint because any change made to
the algorithm of one of the tests must be propagated to all similar tests.
A Parameterized Test offers a way to reuse the same test logic in many Test
Methods (page 348).
Setup
Exercise
Verify
Teardown
Fixture
SUT
Test
Method1
Test
Method2
Test
Method n
Data
Data
Data
Setup
Exercise
Verify
Teardown
Fixture
SUT
Test
Method1
Test
Method2
Test
Method n
Data
Data
Data
Parame-
terized Test
Parameterized Test