Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
608
Chapter 24 Test Organization Patterns
How It Works
The solution, of course, is to factor out the common logic into a utility method.
When this logic includes all four parts of the entire Four-Phase Test (page 358)
life cycle—that is, fi xture setup, exercise SUT, result verifi cation, and fi xture
teardown—we call the resulting utility method a Parameterized Test. This kind
of test gives us the best coverage with the least code to maintain and makes it
very easy to add more tests as they are needed.
If the right utility method is available to us, we can reduce a test that would
otherwise require a series of complex steps to a single line of code. As we detect
similarities between our tests, we can factor out the commonalities into a Test
Utility Method (page 599) that takes only the information that differs from test to
test as its arguments. The Test Methods pass in as parameters any information
that the Parameterized Test requires to run and that varies from test to test.
When to Use It
We can use a Parameterized Test whenever Test Code Duplication (page 213)
results from several tests implementing the same test algorithm but with slightly
different data. The data that differs becomes the arguments passed to the Param-
eterized Test, and the logic is encapsulated by the utility method. A Parameterized
Test also helps us avoid Obscure Tests (page 186); by reducing the number of
times the same logic is repeated, it can make the Testcase Class (page 373) much
more compact. A Parameterized Test is also a good steppingstone to a Data-
Driven Test (page 288); the name of the Parameterized Test maps to the verb or
“action word” of the Data-Driven Test, and the parameters are the attributes.
If our extracted utility method doesn’t do any fi xture setup, it is called a
Verifi cation Method (see Custom Assertion on page 474). If it also doesn’t
exercise the SUT, it is called a Custom Assertion.
Implementation Notes
We need to ensure that the Parameterized Test has an Intent-Revealing Name
[SBPP] so that readers of the test will understand what it is doing. This name
should imply that the test encompasses the whole life cycle to avoid any con-
fusion. One convention is to start or end the name in “test”; the presence of
parameters conveys the fact that the test is parameterized. Most members of
the xUnit family that implement Test Discovery (page 393) will create only
Testcase Objects (page 382) for “no arg” methods that start with “test,” so this
restriction shouldn’t prevent us from starting our Parameterized Test names
with “test.” At least one member of the xUnit family—MbUnit—implements
Parame-
terized Test
609
Parameterized Tests at the Test Automation Framework (page 298) level.
Extensions are becoming available for other members of the xUnit family, with
DDSteps for JUnit being one of the fi rst to appear.
Testing zealots would advocate writing a Self-Checking Test (see page 26) to
verify the Parameterized Test. The benefi ts of doing so are obvious—including
increased confi dence in our tests—and in most cases it isn’t that hard to do. It is
a bit harder than writing unit tests for a Custom Assertion because of the inter-
action with the SUT. We will likely need to replace the SUT
2
with a Test Double
so that we can observe how it is called and control what it returns.
Variation: Tabular Test
Several early reviewers of this book wrote to me about a variation of Param-
eterized Test that they use regularly: the Tabular Test. The essence of this test
is the same as that for a Parameterized Test, except that the entire table of
values resides in a single Test Method. Unfortunately, this approach makes
the test an Eager Test (see Assertion Roulette on page 224) because it verifi es
many test conditions. This issue isn’t a problem when all of the tests pass, but
it does lead to a lack of Defect Localization (see page 22) when one of the
“rows” fails.
Another potential problem is that “row tests” may depend on one another
either on purpose or by accident because they are running on the same Testcase
Object; see Incremental Tabular Test for an example of this behavior.
Despite these potential issues, Tabular Tests can be a very effective way to
test. At least one member of the xUnit family implements Tabular Tests at the
framework level: MbUnit provides an attribute [RowTest] to indicate that a test is a
Parameterized Test and another attribute [Row(x,y,...)] to specify the parameters
to be passed to it. Perhaps it will be ported to other members of the xUnit family?
(Hint, hint!)
Variation: Incremental Tabular Test
An Incremental Tabular Test is a variant of the Tabular Test pattern in which we
deliberately build on the fi xture left over by the previous rows of the test. It is
identical to a deliberate form of Interacting Tests (see Erratic Test on page 228)
2
The terminology of SUT becomes very confusing in this case because we cannot replace the
SUT with a Test Double if it truly is the SUT. Strictly speaking, we are replacing the object
that would normally be the SUT with respect to this test. Because we are actually verifying
the behavior of the
Parameterized Test, whatever normally plays the role of SUT for this test
now becomes a DOC. (My head is starting to hurt just describing this; fortunately, it really
isn’t very complicated and will make a lot more sense when you actually try it out.)
Parameterized Test
Parame-
terized Test
Also known as:
Row Test
610
Chapter 24 Test Organization Patterns
called Chained Tests (page 454), except that all the tests reside within the same
Test Method. The steps within the Test Method act somewhat like the steps of a
“DoFixture” in Fit but without individual reporting of failed steps.
3
Variation: Loop-Driven Test
When we want to test the SUT with all the values in a particular list or range, we
can call the Parameterized Test from within a loop that iterates over the values
in the list or range. By nesting loops within loops, we can verify the behavior
of the SUT with combinations of input values. The main requirement for doing
this type of testing is that we must either enumerate the expected result for each
input value (or combination) or use a Calculated Value (see Derived Value on
page 718) without introducing Production Logic in Test (see Conditional Test
Logic on page 200). A Loop-Driven Test suffers from many of the same issues
associated with a Tabular Test, however, because we are hiding many tests inside
a single Test Method (and, therefore, Testcase Object).
Motivating Example
The following example includes some of the runit (Ruby Unit) tests from the Web
site publishing infrastructure I built in Ruby while writing this book. All of the
Simple Success Tests (see Test Method) for my cross-referencing tags went through
the same sequence of steps: defi ning the input XML, defi ning the expected HTML,
stubbing out the output fi le, setting up the handler for the XML, extracting the
resulting HTML, and comparing it with the expected HTML.
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'/>"
expectedHtml = "<a href='abc.html'>abc</a>"
3
This is because most members of the xUnit terminate the Test Method on the fi rst failed
assertion.
Parame-
terized Test
611
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
Even though we have already factored out much of the common logic into the
setupHandler method, some Test Code Duplication remains. In my case, I had at
least 20 tests that followed this same pattern (with lots more on the way), so I
felt it was worthwhile to make these tests really easy to write.
Refactoring Notes
Refactoring to a Parameterized Test is a lot like refactoring to a Custom Asser-
tion. The main difference is that we include the calls to the SUT made as part of
the exercise SUT phase of the test within the code to which we apply the Extract
Method [Fowler] refactoring. Because these tests are virtually identical once we
have defi ned our fi xture and expected results, the rest can be extracted into the
Parameterized Test.
Example: Parameterized Test
In the following tests, we have reduced each test to two steps: initializing two
variables and calling a utility method that does all the real work. This utility
method is a Parameterized Test.
def test_extref
sourceXml = "<extref id='abc' />"
expectedHtml = "<a href='abc.html'>abc</a>"
generateAndVerifyHtml(sourceXml,expectedHtml,"<extref>")
end
def test_testterm_normal
sourceXml = "<testterm id='abc'/>"
expectedHtml = "<a href='abc.html'>abc</a>"
generateAndVerifyHtml(sourceXml,expectedHtml,"<testterm>")
Parameterized Test
Parame-
terized Test
612
Chapter 24 Test Organization Patterns
end
def test_testterm_plural
sourceXml = "<testterms id='abc'/>"
expectedHtml = "<a href='abc.html'>abcs</a>"
generateAndVerifyHtml(sourceXml,expectedHtml,"<plural>")
end
The succinctness of these tests is made possible by defi ning the Parameterized
Test as follows:
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
What distinguishes this Parameterized Test from a Verifi cation Method is that
it contains the fi rst three phases of the Four-Phase Test (from setup to verify),
whereas the Verifi cation Method performs only the exercise SUT and verify re-
sult phases. Note that our tests did not need the teardown phase because we are
using Garbage-Collected Teardown (page 500).
Example: Independent Tabular Test
Here’s an example of the same tests coded as a single Independent Tabular
Test:
def test_a_href_Generation
row( "extref" ,"abc","abc.html","abc" )
row( "testterm" ,'abc',"abc.html","abc" )
row( "testterms",'abc',"abc.html","abcs")
end
def row( tag, id, expected_href_id, expected_a_contents)
sourceXml = "<" + tag + " id='" + id + "'/>"
expectedHtml = "<a href='" + expected_href_id + "'>"
+ expected_a_contents + "</a>"
msg = "<" + tag + "> "
generateAndVerifyHtml( sourceXml, expectedHtml, msg)
end
Parame-
terized Test
613
Isn’t this a nice, compact representation of the various test conditions? I simply
did an In-line Temp [Fowler] refactoring on the local variables sourceXml and
expectedHtml in the argument list of generateAndVerify and “munged” the various
Test Methods together into one. Most of the work involved something we won’t
have to do in real life: squeeze the table down to fi t within the page-width limit
for this book. That constraint forced me to abridge the text in each row and
rebuild the HTML and the expected XML within the row method. I chose the
name row to better align this example with the MbUnit example provided later in
this section but I could have called it something else like test_element.
Unfortunately, from the Test Runner’s (page 377) perspective, this is a single
test, unlike the earlier examples. Because the tests all reside within the same
Test Method, a failure in any row other than the last will cause a loss of infor-
mation. In this example, we need not worry about Interacting Tests because
generateAndVerify builds a new test fi xture each time it is called. In the real world,
however, we have to be aware of that possibility.
Example: Incremental Tabular Test
Because a Tabular Test is defi ned in a single Test Method, it will run on a single
Testcase Object. This opens up the possibility of building up series of actions.
Here’s an example provided by Clint Shank on his blog:
public class TabularTest extends TestCase {
private Order order = new Order();
private static final double tolerance = 0.001;
public void testGetTotal() {
assertEquals("initial", 0.00, order.getTotal(), tolerance);
testAddItemAndGetTotal("first", 1, 3.00, 3.00);
testAddItemAndGetTotal("second",3, 5.00, 18.00);
// etc.
}
private void testAddItemAndGetTotal( String msg,
int lineItemQuantity,
double lineItemPrice,
double expectedTotal) {
// setup
LineItem item = new LineItem( lineItemQuantity,
lineItemPrice);
// exercise SUT
order.addItem(item);
// verify total
assertEquals(msg,expectedTotal,order.getTotal(),tolerance);
}
}
Parameterized Test
Parame-
terized Test
614
Chapter 24 Test Organization Patterns
Note how each row of the Incremental Tabular Test builds on what was already
done by the previous row.
Example: Tabular Test with Framework Support (MbUnit)
Here’s an example from the MbUnit documentation that shows how to use the
[RowTest] attribute to indicate that a test is a Parameterized Test and another
attribute [Row(x,y,...)] to specify the parameters to be passed to it.
[RowTest()]
[Row(1,2,3)]
[Row(2,3,5)]
[Row(3,4,8)]
[Row(4,5,9)]
public void tAdd(Int32 x, Int32 y, Int32 expectedSum)
{
Int32 Sum;
Sum = this.Subject.Add(x,y);
Assert.AreEqual(expectedSum, Sum);
}
Except for the syntactic sugar of the [Row(x,y,...)] attributes, this code sure looks
similar to the previous example. It doesn’t suffer from the loss of Defect Local-
ization, however, because each row is considered a separate test. It would be a
simple matter to convert the previous example to this format using the “fi nd and
replace” feature in a text editor.
Example: Loop-Driven Test (Enumerated Values)
The following test uses a loop to exercise the SUT with various sets of input
values:
public void testMultipleValueSets() {
// Set up fixture
Calculator sut = new Calculator();
TestValues[] testValues = {
new TestValues(1,2,3),
new TestValues(2,3,5),
new TestValues(3,4,8), // special case!
new TestValues(4,5,9)
};
for (int i = 0; i < testValues.length; i++) {
TestValues values = testValues[i];
// Exercise SUT
int actual = sut.calculate( values.a, values.b);
// Verify result
Parame-
terized Test
615
assertEquals(message(i), values.expectedSum, actual);
}
}
private String message(int i) {
return "Row "+ String.valueOf(i);
}
In this case we enumerated the expected value for each set of test inputs. This
strategy avoids Production Logic in Test.
Example: Loop-Driven Test (Calculated Values)
This next example is a bit more complex:
public void testCombinationsOfInputValues() {
// Set up fixture
Calculator sut = new Calculator();
int expected; // TBD inside loops
for (int i = 0; i < 10; i++) {
for (int j = 0; j < 10; j++) {
// Exercise SUT
int actual = sut.calculate( i, j );
// Verify result
if (i==3 & j==4) // Special case
expected = 8;
else
expected = i+j;
assertEquals(message(i,j), expected, actual);
}
}
}
private String message(int i, int j) {
return "Cell( " + String.valueOf(i)+ ","
+ String.valueOf(j) + ")";
}
Unfortunately, it suffers from Production Logic in Test because of the need to
deal with the special case.
Further Reading
See the documentation for MbUnit for more information on the [RowTest] and
[Row()] attributes. Likewise, see http://www.ddsteps.org for a description of
the DDSteps extension for JUnit; while its name suggests a tool that supports
Parameterized Test
Parame-
terized Test
616
Chapter 24 Test Organization Patterns
Data-Driven Testing, the examples given are Parameterized Tests. More argu-
ments for Tabular Test can be found on Clint Shank’s blog at http://clintshank.
javadevelopersjournal.com/tabulartests.htm.
Parame-
terized Test
617
Testcase Class per Class
How do we organize our Test Methods onto Testcase Classes?
We put all the Test Methods for one SUT class onto a single Testcase Class.
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 Class is a simple way to start off organizing our
tests.
How It Works
We create a separate Testcase Class for each class we wish to test. Each Testcase
Class acts as a home to all the Test Methods that are used to verify the behavior
of the SUT class.
TestcaseClass
Fixture B
Fixture A
SUT Class
testMethod_B_1
testMethod_B_2
testMethod_A_1
testMethod_A_2
feature_1
feature_2
Exercise
Exercise
Creation
Creation
TestcaseClass
Fixture B
Fixture A
SUT Class
testMethod_B_1
testMethod_B_2
testMethod_A_1
testMethod_A_2
feature_1
feature_2
Exercise
Exercise
Creation
Creation
Testcase Class per Class
Testcase
Class per
Class