Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
638
Chapter 24 Test Organization Patterns
Testcase Superclass
Where do we put our test code when it is in reusable Test Utility Methods?
We inherit reusable test-specifi c logic from an abstract
Testcase Super class.
As we write tests, we will invariably fi nd ourselves needing to repeat the same logic
in many, many tests. Initially, we may just “clone and twiddle” as we write addi-
tional tests that need the same logic. Ultimately, we may introduce Test Utility Meth-
ods (page 599) to hold this logic—but where do we put the Test Utility Methods?
A Testcase Superclass is one option as a home for our Test Utility Methods.
How It Works
We defi ne an abstract superclass to hold the reusable Test Utility Method that
should be available to several Testcase Classes (page 373). We make the methods
that will be reused visible to subclasses (e.g., protected in Java). We then use this
abstract class as the superclass (base class) for any tests that wish to reuse the
logic. The logic can be accessed simply by calling the method as though it were
defi ned on the Testcase Class itself.
Testcase
Class
testMethod_1
testMethod_n
Fixture
Testcase
Superclass
Test Utility
Method_1
SUT
Test Utility
Method_2
Testcase
Class
testMethod_1
testMethod_n
Fixture
Testcase
Superclass
Test Utility
Method_1
SUT
Test Utility
Method_2
Testcase
Superclass
Also known as:
Abstract
Testcase,
Abstract Test
Fixture,
Testcase
Baseclass
639
When to Use It
We can use a Testcase Superclass if we wish to reuse Test Utility Methods between
several Testcase Classes and can fi nd or defi ne a Testcase Superclass from which
we can subclass all tests that require the logic.
This pattern assumes that our programming language supports inheritance,
we are not already using inheritance for some other confl icting purpose, and
the Test Utility Method doesn’t need access to specifi c types that are not visible
from the Testcase Superclass.
The decision between a Testcase Superclass and a Test Helper (page 643) comes
down to type visibility. The client classes need to see the Test Utility Method, and
the Test Utility Method needs to see the types and classes it depends on. 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 we defi ne for our project or company. If the Test Utility Method
depends on types/classes that cannot be seen from a single place that all clients
can access, it may be necessary to put it on a Test Helper in the appropriate test
package or subsystem.
Variation: Test Helper Mixin
In languages that support mixins, Test Helper Mixins give us the best of both
worlds. As with a Test Helper, we can choose which Test Helper Mixins to in-
clude without being constrained by a single-inheritance hierarchy. As with a Test
Helper Object (see Test Helper), we can hold a test-specifi c state in the mixin but
we don’t have to instantiate and delegate that task to a separate object. As with a
Testcase Superclass, we can access everything as methods and attributes on self.
Implementation Notes
In variants of xUnit that require all Testcase Classes to be subclasses of a Test-
case Superclass provided by the Test Automation Framework (page 298), we
defi ne that class as the superclass of our Testcase Superclass. In variants that use
annotations or method attributes to identify the Test Method (page 348), we can
subclass any class that we fi nd useful.
We can implement the methods on the Testcase Superclass either as class
methods or as instance methods. For any stateless Test Utility Methods, it is
perfectly reasonable to use class methods. If it isn’t possible to use class meth-
ods for some reason, we can work with instance methods. Either way, because
the methods are inherited, we can access them as though they were defi ned
on the Testcase Class itself. If our language supports managing the visibility
Testcase Superclass
Testcase
Superclass
640
Chapter 24 Test Organization Patterns
of methods, we must ensure that we make the methods visible enough (e.g.,
protected in Java).
Motivating Example
The following example shows a Test Utility Method that is on the Testcase
Class:
public class TestRefactoringExample extends TestCase {
public void testAddOneLineItem_quantity1() {
Invoice inv = createAnonInvoice();
LineItem expItem = new LineItem(inv, product, QUANTITY);
// Exercise
inv.addItemQuantity(product, QUANTITY);
// Verify
assertInvoiceContainsOnlyThisLineItem(inv, expItem);
}
void assertInvoiceContainsOnlyThisLineItem(
Invoice inv,
LineItem expItem) {
List lineItems = inv.getLineItems();
assertEquals("number of items", lineItems.size(), 1);
LineItem actual = (LineItem)lineItems.get(0);
assertLineItemsEqual("",expItem, actual);
}
}
This Test Utility Method is not reusable outside this particular class or its
subclasses.
Refactoring Notes
We can make the Test Utility Method more reusable by moving it to a Testcase
Superclass by using a Pull Up Method [Fowler] refactoring. Because the method
is inherited by our Testcase Class, we can access it as if the method were
defi ned locally. If the Test Utility Method accesses any instance variables, we
must perform a Pull Up Field [Fowler] refactoring to move those variables to
a place where the Test Utility Method can see them. In languages that have
visibility restrictions, we may need to make the fi elds visible to subclasses (e.g.,
default or protected in Java) if Test Methods on the Testcase Class need to access
the fi elds as well.
Testcase
Superclass
641
Example: Testcase Superclass
Because the method is inherited by our Testcase Class, we can access it as if it
were defi ned locally. Thus the usage looks identical.
public class TestRefactoringExample extends OurTestCase {
public void testAddItemQuantity_severalQuantity_v12(){
// Fixture Setup
Customer cust = createACustomer(new BigDecimal("30"));
Product prod = createAProduct(new BigDecimal("19.99"));
Invoice invoice = createInvoice(cust);
// Exercise SUT
invoice.addItemQuantity(prod, 5);
// Verify Outcome
LineItem expected = new LineItem(invoice, prod, 5,
new BigDecimal("30"), new BigDecimal("69.96"));
assertContainsExactlyOneLineItem(invoice, expected);
}
}
The only difference is the class in which the method is defi ned and its visibility:
public class OurTestCase extends TestCase {
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);
}
}
Example: Test Helper Mixin
Here are some tests written in Ruby using Test::Unit:
def test_extref
# setup
sourceXml = "<extref id='abc'/>"
expectedHtml = "<a href='abc.html'>abc</a>"
mockFile = MockFile.new
@handler = setupHandler(sourceXml, mockFile)
# execute
@handler.printBodyContents
# verify
assert_equals_html( expectedHtml, mockFile.output,
"extref: html output")
end
def testTestterm_normal
sourceXml = "<testterm id='abc'/>"
Testcase Superclass
Testcase
Superclass
642
Chapter 24 Test Organization Patterns
expectedHtml = "<a href='abc.html'>abc</a>"
mockFile = MockFile.new
@handler = setupHandler(sourceXml, mockFile)
@handler.printBodyContents
assert_equals_html( expectedHtml, mockFile.output,
"testterm: html output")
end
def testTestterm_plural
sourceXml ="<testterms id='abc'/>"
expectedHtml = "<a href='abc.html'>abcs</a>"
mockFile = MockFile.new
@handler = setupHandler(sourceXml, mockFile)
@handler.printBodyContents
assert_equals_html( expectedHtml, mockFile.output,
"testterms: html output")
end
These tests contain a fair bit of Test Code Duplication (page 213). We can address
this issue by using an Extract Method [Fowler] refactoring to create a Test Utility
Method. We can then make the Test Utility Method more reusable by moving it
to a Test Helper Mixin using a Pull Up Method refactoring. Because the mixed-in
functionality is considered part of our Testcase Class, we can access it as if it were
defi ned locally. Thus the usage looks identical.
class CrossrefHandlerTest < Test::Unit::TestCase
include HandlerTest
def test_extref
sourceXml = "<extref id='abc' />"
expectedHtml = "<a href='abc.html'>abc</a>"
generateAndVerifyHtml(sourceXml,expectedHtml,"<extref>")
end
The only difference is the location where the method is defi ned and its visibility.
In particular, Ruby requires mixins to be defi ned in a module rather than a class.
module HandlerTest
def generateAndVerifyHtml( sourceXml, expectedHtml,
message, &block)
mockFile = MockFile.new
sourceXml.delete!("\t")
@handler = setupHandler(sourceXml, mockFile )
block.call unless block == nil
@handler.printBodyContents
actual_html = mockFile.output
assert_equal_html( expectedHtml,
actual_html,
message + "html output")
actual_html
end
Testcase
Superclass
643
Test Helper
Where do we put our test code when it is in reusable Test Utility Methods?
We defi ne a helper class to hold any Test Utility Methods we want
to reuse in several tests.
As we write tests, we will invariably fi nd ourselves needing to repeat the same
logic in many, many tests. Initially, we may just “clone and twiddle” as we write
additional tests that need the same logic. Ultimately, we may introduce Test
Utility Methods (page 599) to hold this logic—but where should we put such
reusable logic?
A Test Helper is one possible choice of home for reusable test logic.
How It Works
We defi ne a separate class to hold the reusable Test Utility Methods that should
be available to several Testcase Classes (page 373). In each test that wishes to use
this logic, we access the logic either using static method calls or via an instance
created specifi cally for the purpose.
When to Use It
We can use a Test Helper if we wish to share logic or variables between several
Testcase Classes and cannot (or choose not to) fi nd or defi ne a Testcase Super-
class (page 638) from which we might otherwise subclass all tests that require
this logic. We might pursue this course in several circumstances: Perhaps our
Testcase
Class
testMethod_1
testMethod_n
Fixture
SUT
Test Helper
Test Utility
Method_1
Test Utility
Method_2
Testcase
Class
testMethod_1
testMethod_n
Fixture
SUT
Test Helper
Test Utility
Method_1
Test Utility
Method_2
Test Helper
Test Helper
644
Chapter 24 Test Organization Patterns
programming language doesn’t support inheritance (e.g., Visual Basic 5 or 6),
perhaps we are already using inheritance for some other confl icting purpose,
or perhaps the Test Utility Method needs access to specifi c types that are not
visible from the Testcase Superclass.
The decision between a Test Helper and a Testcase Superclass comes down
to type visibility. The client classes need to see the Test Utility Method, and the
Test Utility Method needs to see all the types and classes it depends on. 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 we defi ne for our project or company. If the Test Utility
Method depends on types/classes that cannot be seen from a single place that all
clients can access, it may be necessary to put it on a Test Helper in the appropri-
ate 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 Fixture Registry
A Registry [PEAA] is a well-known object that can be accessed from anywhere
in a program. We can use the Registry to store and retrieve objects from dif-
ferent parts of our program or tests. (Registry objects are often confused with
Singletons [GOF], which are also well known but have only a single instance.
With a Registry object, there may be one or more instances—we don’t really
care.) A Test Fixture Registry gives the tests the ability to access the same fi xture
as other tests in the same test run. Depending on how we implement our Test
Helper, we may choose to provide a different instance of the Test Fixture Regis-
try for each Test Runner (page 377) in an effort to prevent a Test Run War (see
Erratic Test on page 228). A common example of a Test Fixture Registry is the
Database Sandbox (page 650).
A Test Fixture Registry is typically used with a Setup Decorator (page 447) or
with Lazy Setup (page 435); it isn’t needed with Suite Fixture Setup (page 441)
because only tests on the same Testcase Class need to share the fi xture. In such
a case, using a fi xture holding class variable works well for this purpose.
Variation: Object Mother
The Object Mother pattern is simply an aggregate of several other patterns, each
of which makes a small but signifi cant contribution to making the test fi xture easier
to manage. The Object Mother consists of one or more Test Helpers that provide
Creation Methods (page 415) and Attachment Methods (see Creation Method),
which our tests then use to create ready-to-use test fi xture objects. Object Mothers
Test Helper
645
often provide several Creation Methods that create instances of the same class,
where each method results in a test object in a different starting state (a Named
State Reaching Method; see Creation Method). The Object Mother may also have
the ability to delete the objects it creates automatically—an example of Automated
Teardown (page 503).
Because there is no single, crisp defi nition of what someone means by “Object
Mother,” it is advisable to refer to the individual patterns (such as Automated
Teardown) when referring to specifi c capabilities of the Object Mother.
Implementation Notes
The methods on the Test Helper can be implemented as either class methods or
instance methods depending on the degree to which we want to keep the tests
from interacting.
Variation: Test Helper Class
If all of the Test Utility Methods are stateless, the simplest approach is to imple-
ment the functionality of the Test Helper as class methods and then to have the
tests access those methods using the ClassName.methodName (or equivalent) notation.
If we need to hold references to fi xture objects, we could place them in class
variables. We need to be careful to avoid inadvertently creating a Shared
Fixture (page 317), however—unless, of course, that is exactly what we are
trying to do. In such a case, we are actually building a Test Fixture Registry.
Variation: Test Helper Object
If we can’t use class methods for some reason, we can work with instance meth-
ods instead. In this case, the client test will need to create an instance of the Test
Helper class and store it in an instance variable; the methods can then be accessed
via this variable. This pattern is a good approach when the Test Helper holds
references to fi xture or SUT objects and we want to make sure that we don’t creep
into a Shared Fixture situation. It is also useful when the Test Helper stores expec-
tations for a set of Mock Objects (page 544), because this pattern ensures that we
can verify the calls are interleaved between the Mock Objects correctly.
Motivating Example
The following example shows a Test Utility Method that is on the Testcase Class:
public class TestUtilityExample extends TestCase {
public void testAddOneLineItem_quantity1() {
Test Helper
Test Helper
646
Chapter 24 Test Organization Patterns
Invoice inv = createAnonInvoice();
LineItem expItem = new LineItem(inv, product, QUANTITY);
// Exercise
inv.addItemQuantity(product, QUANTITY);
// Verify
assertInvoiceContainsOnlyThisLineItem(inv, expItem);
}
void assertInvoiceContainsOnlyThisLineItem(
Invoice inv,
LineItem expItem) {
List lineItems = inv.getLineItems();
assertEquals("number of items", lineItems.size(), 1);
LineItem actual = (LineItem)lineItems.get(0);
assertLineItemsEqual("",expItem, actual);
}
}
This Test Utility Method is not reusable outside this particular class.
Refactoring Notes
We can make a Test Utility Method more reusable by moving it to a Test Helper
class. This transformation is often as simple as doing a Move Method [Fowler]
refactoring to our Test Helper class. One potential problem arises when we have
used instance variables to pass arguments to or return data from the Test Utility
Method. These “global data” need to be converted to explicit arguments and
return values before we can perform the Move Method refactoring.
Example: Test Helper with Class Methods
In this modifi ed version of the preceding test, we have turned the Test Utility
Method into a class method on a Test Helper Class so we can access it via the
classname without creating an instance:
public class TestUtilityExample extends TestCase {
public void testAddOneLineItem_quantity1_staticHelper() {
Invoice inv = createAnonInvoice();
LineItem expItem = new LineItem(inv, product, QUANTITY);
// Exercise
inv.addItemQuantity(product, QUANTITY);
// Verify
TestHelper.assertContainsExactlyOneLineItem(inv, expItem);
}
}
Test Helper
647
Example: Test Helper with Instance Methods
In this example, we have moved the Test Utility Method to a Test Helper as an
instance method. Note that we must now access the method via an object refer-
ence (a variable that holds an instance of the Test Helper).
public class TestUtilityExample extends TestCase {
public void testAddOneLineItem_quantity1_instanceHelper() {
Invoice inv = createAnonInvoice();
LineItem expItem = new LineItem(inv, product, QUANTITY);
// Exercise
inv.addItemQuantity(product, QUANTITY);
// Verify
TestHelper helper = new TestHelper();
helper.assertInvContainsExactlyOneLineItem(inv, expItem);
}
}
Test Helper
Test Helper