Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
438
protected void tearDown() throws Exception {
removeStandardAirportsAndFlights();
}
public void testGetFlightsByOriginAirport_NoFlights_td()
throws Exception {
// Fixture Setup
BigDecimal outboundAirport = createTestAirport("1OF");
try {
// Exercise System
List flightsAtDestination1 =
facade.getFlightsByOriginAirport(outboundAirport);
// Verify Outcome
assertEquals(0,flightsAtDestination1.size());
} finally {
facade.removeAirport(outboundAirport);
}
}
public void testGetFlightsByFromAirport_OneOutboundFlight()
throws Exception {
// Exercise System
List flightsAtOrigin = facade.getFlightsByOriginAirport(
oneOutboundFlight.getOriginAirportId());
// Verify Outcome
assertOnly1FlightInDtoList( "Flights at origin",
oneOutboundFlight,
flightsAtOrigin);
}
public void testGetFlightsByFromAirport_TwoOutboundFlights()
throws Exception {
FlightDto[] outboundFlights =
findTwoOutboundFlightsFromOneAirport();
// Exercise System
List flightsAtOrigin = facade.getFlightsByOriginAirport(
outboundFlights[0].getOriginAirportId());
// Verify Outcome
assertExactly2FlightsInDtoList( "Flights at origin",
outboundFlights,
flightsAtOrigin);
}
This doesn’t speed up our tests one bit because the Test Automation Framework
calls the setUp and tearDown methods for each Testcase Object. All we have done
is moved the code. We need to fi nd a way to set up the fi xture only once per
test run.
Lazy Setup
Chapter 20 Fixture Setup Patterns
439
Refactoring Notes
We can reduce the number of times we set up the fi xture by converting this test to
Lazy Setup. Because the fi xture setup is already handled by the setUp method, we
need simply insert the Lazy Initialization logic into the setUp method so that only
the fi rst test will cause it to be run. We must not forget to remove the tearDown logic,
because it will render the Lazy Initialization logic useless if it removes the fi xture
after each Test Method has run! Sorry, but there is nowhere that we can move
this logic to so that it will be run after the last Test Method has completed if our
xUnit family member doesn’t support Suite Fixture Setup.
Example: Lazy Setup
Here is the same test refactored to use Lazy Setup:
protected void setUp() throws Exception {
if (sharedFixtureInitialized) {
return;
}
facade = new FlightMgmtFacadeImpl();
setupStandardAirportsAndFlights();
sharedFixtureInitialized = true;
}
protected void tearDown() throws Exception {
// Cannot delete any objects because we don't know
// whether this is the last test
}
While there is a tearDown method on AirportFixture, there is no way to know when
to call it! That’s the main consequence of using Lazy Setup. Because the variables
are static, they will not go out of scope; hence the fi xture will not be garbage col-
lected until the class is unloaded or reloaded.
The tests are unchanged from the Implicit Setup version:
public void testGetFlightsByFromAirport_OneOutboundFlight()
throws Exception {
FlightDto outboundFlight = findOneOutboundFlight();
// Exercise System
List flightsAtOrigin = facade.getFlightsByOriginAirport(
outboundFlight.getOriginAirportId());
// Verify Outcome
assertOnly1FlightInDtoList( "Flights at origin",
outboundFlight,
flightsAtOrigin);
}
Lazy Setup
Lazy Setup
440
public void testGetFlightsByFromAirport_TwoOutboundFlights()
throws Exception {
FlightDto[] outboundFlights =
findTwoOutboundFlightsFromOneAirport();
// Exercise System
List flightsAtOrigin = facade.getFlightsByOriginAirport(
outboundFlights[0].getOriginAirportId());
// Verify Outcome
assertExactly2FlightsInDtoList( "Flights at origin",
outboundFlights,
flightsAtOrigin);
}
Lazy Setup
Chapter 20 Fixture Setup Patterns
441
Suite Fixture Setup
How do we cause the Shared Fixture to be built before the
fi rst test method that needs it?
We build/destroy the shared fi xture in special methods called by the Test
Automation Framework before/after the fi rst/last Test Method is called.
Shared Fixtures (page 317) are commonly used to reduce the amount of per-test
overhead required to set up the fi xture. Sharing a fi xture involves extra test program-
ming effort because we must create the fi xture and have a way of discovering the
fi xture in each test. Regardless of how the fi xture is accessed, it must be initialized
(constructed) before it is used.
Suite Fixture Setup is one way to initialize the fi xture if all the Test Meth-
ods (page 348) that need it are defi ned on the same Testcase Class (page 373).
How It Works
We implement or override a pair of methods that the Test Automation Frame-
work (page 298) calls automatically. The name or annotation of these methods
varies between members of the xUnit family but all work the same way: The
framework calls the Suite Fixture Setup method before it calls the setUp method
for the fi rst Test Method; it calls the Suite Fixture Teardown method after it
calls the tearDown method for the fi nal Test Method. (I would have preferred to
Testcase Object
Testcase Object
Fixture
SUT
Inline Setup
Exercise
Verify
Inline Teardown
Inline Setup
Exercise
Verify
Inline Teardown
Implicit setUp
Implicit tearDown
Implicit setUp
Implicit tearDown
SuiteFixture setUp
SuiteFixture tearDown
TestSuite Object
for
Testcase Class
Setup
Testcase Object
Testcase Object
Fixture
SUT
Inline Setup
Exercise
Verify
Inline Teardown
Inline Setup
Exercise
Verify
Inline Teardown
Implicit setUp
Implicit tearDown
Implicit setUp
Implicit tearDown
SuiteFixture setUp
SuiteFixture tearDown
TestSuite Object
for
Testcase Class
Setup
Suite Fixture Setup
Suite
Fixture
Setup
442
say, “method on the fi rst/fi nal Testcase Object” but that isn’t true: NUnit, unlike
other members of the xUnit family, creates only a single Testcase Object. See the
sidebar “There’s Always an Exception” on page 384 for details.)
When to Use It
We can use Suite Fixture Setup when we have a test fi xture we wish to share
between all Test Methods of a single Testcase Class and our variant of xUnit sup-
ports this feature. This pattern is particularly useful if we need to tear down the
fi xture after the last test is run. At the time of writing this book, only VbUnit,
NUnit, and JUnit 4.0 supported Suite Fixture Setup “out of the box.” Nevertheless,
it is not diffi cult to add this capability in most variants of xUnit.
If we need to share the fi xture more widely, we must use either a Prebuilt
Fixture (page 429), a Setup Decorator (page 447), or Lazy Setup (page 435).
If we don’t want to share the actual instance of the fi xture but we do want to
share the code to set up the fi xture, we can use Implicit Setup (page 424) or
Delegated Setup (page 411).
The main reason for using a Shared Fixture, and hence Suite Fixture Setup,
is to overcome the problem of Slow Tests (page 253) caused by too many test
fi xture objects being created each time every test is run. Of course, a Shared
Fixture can lead to Interacting Tests (see Erratic Test on page 228) or even
a Test Run War (see Erratic Test); the sidebar “Faster Tests Without Shared
Fixtures” (page 319) describes other ways to solve this problem.
Implementation Notes
For Suite Fixture Setup to work properly, we must ensure that the fi xture is
remembered between calls to the Test Methods. This criterion implies we need to
use a class variable, Registry [PEAA], or Singleton [GOF] to hold the references
to the fi xture (except in NUnit; see the sidebar “There’s Always an Exception”
on page 384). The exact implementation varies from one member of the xUnit
family to the next. Here are a few highlights:
• In VbUnit, we implement the interface IFixtureFrame in the Testcase Class,
thereby causing the Test Automation Framework (1) to call the IFixture
Frame_Create
method before the fi rst Test Method is called and (2) to call
the IFixtureFrame_Destroy method after the last Test Method is called.
• In NUnit, the attributes [TestFixtureSetUp] and [TestFixtureTearDown] are
used inside a test fi xture to designate the methods to be called (1) once
Suite
Fixture
Setup
Chapter 20 Fixture Setup Patterns
443
prior to executing any of the tests in the fi xture and (2) once after all
tests are completed.
• In JUnit 4.0 and later, the attribute @BeforeClass is used to indicate that a
method should be run once before the fi rst Test Method is executed. The
method with the attribute @AfterClass is run after the last Test Method
is run. JUnit allows these methods to be inherited and overridden; the
subclass’s methods are run between the superclass’s methods.
Just because we use a form of Implicit Setup to invoke the construction and
destruction of the test fi xture, it doesn’t mean that we should dump all the fi xture
setup logic into the Suite Fixture Setup. We can call Creation Methods (page 415)
from the Suite Fixture Setup method to move complex construction logic into
places where it can be tested and reused more easily, such as a Testcase Super-
class (page 638) or a Test Helper (page 643).
Motivating Example
Suppose we have the following test:
[SetUp]
protected void setUp() {
helper.setupStandardAirportsAndFlights();
}
[TearDown]
protected void tearDown() {
helper.removeStandardAirportsAndFlights();
}
[Test]
public void testGetFlightsByOriginAirport_2OutboundFlights(){
FlightDto[] expectedFlights =
helper.findTwoOutboundFlightsFromOneAirport();
long originAirportId = expectedFlights[0].OriginAirportId;
// Exercise System
IList flightsAtOrigin =
facade.GetFlightsByOriginAirport(originAirportId);
// Verify Outcome
AssertExactly2FlightsInDtoList(
expectedFlights[0], expectedFlights[1],
flightsAtOrigin, "Flights at origin");
}
[Test]
public void testGetFlightsByOriginAirport_OneOutboundFlight(){
FlightDto expectedFlight = helper.findOneOutboundFlight();
// Exercise System
Suite Fixture Setup
Suite
Fixture
Setup
444
IList flightsAtOrigin = facade.GetFlightsByOriginAirport(
expectedFlight.OriginAirportId);
// Verify Outcome
AssertOnly1FlightInDtoList( expectedFlight,
flightsAtOrigin, "Outbound flight at origin");
}
Figure 20.1 is the console generated by an instrumented version of these tests.
--------------------
setUp
setupStandardAirportsAndFlights
testGetFlightsByOriginAirport_OneOutboundFlight
tearDown
removeStandardAirportsAndFlights
--------------------
setUp
setupStandardAirportsAndFlights
testGetFlightsByOriginAirport_TwoOutboundFlights
tearDown
removeStandardAirportsAndFlights
--------------------
Figure 20.1 The calling sequence of Implicit Setup and Test Methods. The
setupStandardAirportsAndFlights
method is called before each Test Method. The hori-
zontal lines delineate the Test Method boundaries.
Refactoring Notes
Suppose we want to refactor this example to a Shared Fixture. If we don’t care
about destroying the fi xture when the test run is fi nished, we could use Lazy Setup.
Otherwise, we can convert this example to a Suite Fixture Setup strategy by simply
moving our code from the setUp and tearDown methods to the suiteFixtureSetUp and
suiteFixtureTearDown methods, respectively.
In NUnit, we use the attributes [TestFixtureSetUp] and [TestFixtureTearDown] to
indicate these methods to the Test Automation Framework. If we don’t want
to leave anything in our setUp/tearDown methods, we can simply change the
attributes from [Setup] and TearDown to [TestFixtureSetUp] and [TestFixtureTearDown],
respectively.
Example: Suite Fixture Setup
Here’s the result of our refactoring to Suite Fixture Setup:
[TestFixtureSetUp]
protected void suiteFixtureSetUp()
{
Suite
Fixture
Setup
Chapter 20 Fixture Setup Patterns
445
helper.setupStandardAirportsAndFlights();
}
[TestFixtureTearDown]
protected void suiteFixtureTearDown() {
helper.removeStandardAirportsAndFlights();
}
[SetUp]
protected void setUp() {
}
[TearDown]
protected void tearDown() {
}
[Test]
public void testGetFlightsByOrigin_TwoOutboundFlights(){
FlightDto[] expectedFlights =
helper.findTwoOutboundFlightsFromOneAirport();
long originAirportId = expectedFlights[0].OriginAirportId;
// Exercise System
IList flightsAtOrigin =
facade.GetFlightsByOriginAirport(originAirportId);
// Verify Outcome
AssertExactly2FlightsInDtoList(
expectedFlights[0], expectedFlights[1],
flightsAtOrigin, "Flights at origin");
}
[Test]
public void testGetFlightsByOrigin_OneOutboundFlight() {
FlightDto expectedFlight = helper.findOneOutboundFlight();
// Exercise System
IList flightsAtOrigin = facade.GetFlightsByOriginAirport(
expectedFlight.OriginAirportId);
// Verify Outcome
AssertOnly1FlightInDtoList( expectedFlight,
flightsAtOrigin, "Outbound flight at origin");
}
Now when various methods of the Testcase Class are called, the console looks
like Figure 20.2.
Suite
Fixture
Setup
Suite Fixture Setup
446
suiteFixtureSetUp
setupStandardAirportsAndFlights
--------------------
setUp
testGetFlightsByOriginAirport_OneOutboundFlight
tearDown
--------------------
setUp
testGetFlightsByOriginAirport_TwoOutboundFlights
tearDown
--------------------
suiteFixtureTearDown
removeStandardAirportsAndFlights
Figure 20.2 The calling sequence of Suite Fixture Setup and Test Methods.
The setupStandardAndAirportsAndFlights method is called once only for the Testcase
Class rather than before each Test Method. The horizontal lines delineate the
Test Method boundaries.
The setUp method is still called before each Test Method, along with the suite
FixtureSetUp
method where we are now calling setupStandardAirportsAndFlights to
set up our fi xture. So far, this is no different than Lazy Setup; the difference
arises in that removeStandardAirportsAndFlights is called after the last of our Test
Methods.
About the Name
Naming this pattern was tough because each variant of xUnit that implements
it has a different name for it. Complicating matters is the fact that the Microsoft
camp uses “test fi xture” to mean more than what the Java/Pearl/Ruby/etc. camp
means. I landed on Suite Fixture Setup by focusing on the scope of the Shared
Fixture; it is shared across the test suite for one Testcase Class that spawns a
single Test Suite Object (page 387). The fi xture that is built for the Test Suite
Object could be called a “SuiteFixture.”
Further Reading
See http://www.vbunit.com/doc/Advanced.htm for more information on Suite
Fixture Setup as implemented in VbUnit. See http://nunit.org for more informa-
tion on Suite Fixture Setup as implemented in NUnit.
Suite
Fixture
Setup
Chapter 20 Fixture Setup Patterns
447
Setup Decorator
How do we cause the Shared Fixture to be built before the
fi rst test method that needs it?
We wrap the test suite with a Decorator that sets up the shared test fi xture
before running the tests and tears it down after all tests are done.
If we have chosen to use a Shared Fixture (page 317), whether for reasons of
convenience or out of necessity, and we have chosen not to use a Prebuilt Fix-
ture (page 429), we will need to ensure that the fi xture is built before each test
run. Lazy Setup (page 435) is one strategy we could employ to create the test
fi xture “just in time” for the fi rst test. But if it is critical to tear down the fi xture
after the last test, how do we know that all tests have been completed?
How It Works
A Setup Decorator works by “bracketing” the execution of the entire test suite
with a set of matching setUp and tearDown “bookends.” The pattern Decorator
[GOF] is just what we need to make this happen. We construct a Setup Decora-
tor that holds a reference to the Test Suite Object (page 387) we wish to decorate
and then pass our Decorator to the Test Runner (page 377). When it is time to
Testcase Object
Testcase Object
Fixture
SUT
TestSuite
Object
Inline Setup
Exercise
Verify
Inline Teardown
Inline Setup
Exercise
Verify
Inline Teardown
Implicit setUp
Implicit tearDown
Implicit setUp
Implicit tearDown
Fixture
Setup
Decorator
setUp
tearDown
Testcase Object
Testcase Object
Fixture
SUT
TestSuite
Object
Inline Setup
Exercise
Verify
Inline Teardown
Inline Setup
Exercise
Verify
Inline Teardown
Implicit setUp
Implicit tearDown
Implicit setUp
Implicit tearDown
Fixture
Setup
Decorator
setUp
tearDown
Setup Decorator
Setup
Decorator