Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
668
Chapter 25 Database Patterns
Transaction Rollback Teardown
How do we tear down the Test Fixture when it is in a relational database?
We roll back the uncommitted test transaction as part of the teardown.
A large part of making tests repeatable and robust is ensuring that the test fi x-
ture is torn down after each test. Leftover objects and database records, as well
as open fi les and connections, can at best cause performance degradation and at
worst cause tests to fail or systems to crash. While some of these resources may
be cleaned up automatically by garbage collection, others may be left hanging if
they are not torn down explicitly.
Writing teardown code that can be relied upon to clean up properly in all
possible circumstances is challenging and time-consuming. It involves under-
standing what could be left over for each possible outcome of the test and
writing code to deal with this case. This Complex Teardown (see Obscure Test
on page 186) introduces a fair bit of Conditional Test Logic (page 200) and—
worst of all—Untestable Test Code (see Hard-to-Test Code on page 209).
We can avoid making any lasting changes to the database contents by not
committing the transaction and taking advantage of the rollback capabilities of
the database.
How It Works
Our test starts a new test transaction, sets up the fi xture, exercises the SUT, and
verifi es the outcome of the test. Each of these steps may involve interacting with
Data
Setup
Exercise
Verify
Teardown
SUT
Fixture
Rollback
Start Transaction
Insert
Update
Exercise
Data
Setup
Exercise
Verify
Teardown
SUT
Fixture
Rollback
Start Transaction
Insert
Update
Exercise
Transaction
Rollback
Teardown
669
the database. At the end of the test, the test rolls back the test transaction, which
prevents any of the changes from becoming persistent.
When to Use It
We can use Transaction Rollback Teardown when we are using a Fresh Fix-
ture (page 311) approach with an SUT that includes a database that supports
rolling back a transaction. There are, however, some prerequisites for using
Transaction Rollback Teardown.
In particular, the SUT must expose methods that are normally called in the
context of an existing transaction by a Humble Transaction Controller (see
Humble Object on page 695). That is, the methods should not start their own
transaction and must never commit a transaction. If we are doing test-driven
development, this design will come about as a result of applying the Transac-
tion Rollback Teardown pattern as we write our code. If we are retrofi tting the
tests to existing software, we may need to refactor the code to use a Humble
Transaction Controller before we can use Transaction Rollback Teardown.
The nice thing about Transaction Rollback Teardown is that it leaves the
database in exactly the same state as it was when we started the test, regard-
less of what changes we made to the database contents during the test. As a
result, we do not need to determine what needs to be cleaned up and what does
not. Changes to the database schema or contents do not affect our teardown
logic. Clearly, this pattern is much simpler to apply than Table Truncation Tear-
down (page 661).
The usual caveats apply to any tests that run against a real database; such
tests will take approximately 50 (yes, 50!) times as long to run as tests that
do not access the database. This testing approach will almost surely result in
Slow Tests (page 253) unless we replace the real database with an In-Memory
Database (see Fake Object on page 551) for most of our tests. Because we are
depending on the transactional properties of the database, a simple Fake Data-
base (see Fake Object) will probably not be suffi cient unless it supports ACID.
Another prerequisite with Transaction Rollback Teardown is that we cannot
do anything that results in a commit anywhere in the tests or the code they exer-
cise. The sidebar “Transaction Rollback Pain” on page 670 describes examples
of where commits can sneak in and cause havoc.
Transaction Rollback Teardown
Transaction
Rollback
Teardown
670
Chapter 25 Database Patterns
Transaction Rollback Pain
John Hurst sent me an e-mail in which he described some of the issues his
team had encountered using Transaction Rollback Teardown. He writes:
We used Transaction Rollback Teardown for our database integra-
tion tests for a while, after a discussion on TheServerSide during
which Rod Johnson advocated the approach. I gathered his main
motivation for using it was for performance; a rollback is usually
a lot faster than repriming the database in a new transaction for
the next test. Indeed, we did fi nd it somewhat faster than our pre-
vious approach. We used Spring’s excellent
AbstractTransactionalData-
SourceSpringContextTests
base class, which supports most of what you
need to do for this pattern out of the box.
However, I chose to abandon this pattern after a few months.
Here are the drawbacks I came across with this approach:
1. You lose some test isolation. In the way we implemented this
pattern, anyway, each test assumed the database was in a cer-
tain base starting condition, and the rollback would revert it
to that condition. In our current model, each test is respon-
sible—usually via a base class’s setUp()—for priming the data-
base into a known state.
2. You can’t see what’s in the database when something goes
wrong. If your test fails, you usually want to examine the
database to see what happened. If you’ve rolled back all the
changes, it makes it harder to fi nd the bug.
3. You have to be very careful not to inadvertently commit
during your test. Yes, the code under test has declarative
transaction management, and does nothing surprising. But
we occasionally would need to do things in the test setup
like drop and recreate a sequence to reset its value. This,
being DDL, commits any outstanding transaction—and
confused programmers.
4. You can’t easily mix in tests that do need to commit changes.
Lately I have added some PLSQL stored procedures and tests.
Some of the stored procedures do explicit commits. I cannot
mix these in the same JUnit suite with tests that assume the
database always remains in a certain state.
I apologize if my terminology isn’t consistent with what’s in your
book. Also, my experience is probably a little limited; I’ve only
Transaction
Rollback
Teardown
671
tried this approach in a Spring environment and I prefer to do most
things in a “Spring” way. Finally, I am sure these limitations can be
and are worked around in various ways. It’s just that, for our team,
this pattern turned out to be more trouble than it was worth.
Don’t get me wrong—I DO think the pattern should be included.
I just think the consequences should be noted, and maybe it isn’t
for everyone.
Implementation Notes
A few members of the xUnit family support Transaction Rollback Teardown
directly; open-source extensions may be available for other members. If nothing
is available, coding this teardown logic is not very complicated. The more signifi -
cant implementation consideration is giving the tests access to nontransactional
methods on the SUT. Most domain model objects are nontransactional, so this
requirement should not be a problem for unit tests of domain objects. We are
more likely to experience a problem when we are writing Subcutaneous Tests
(see Layer Test on page 337) against a Service Facade [CJ2EEP] because these
methods often perform transaction control. If this is the case, we will need to
expose a nontransactional version of the methods by refactoring to the Humble
Transaction Controller pattern. We could either use a transactional Decorator
[GOF] as a separate object or simply have the transactional methods delegate to
the nontransactional versions of the methods on self. This approach is called a
Poor Man’s Humble Object (see Humble Object).
If the methods exist but are not visible to the client, we will need to expose
them to the test. We can do so either by making the methods to be tested pub-
lic or by exposing them indirectly via a Test-Specifi c Subclass (page 579). We
could also do an Extract Testable Component (page 735) refactoring to move
the nontransactional versions of the methods to a different class and make them
visible to the test from there.
Any reading of the updated data in the database must occur within the
context of the same transaction. This normally is not a problem except when
we are trying to simulate or test concurrency. If we are using an ORM layer
such as Toplink, (N)Hibernate, or EJB 3.0, we may need to force the ORM
to write the changes made to the objects to the database so that methods that
read the database directly (from within the same transactional context) can
see them. For example, EJB 3.0 provides the EntityManager.fl ush static method
for exactly this purpose.
Transaction Rollback Teardown
Transaction
Rollback
Teardown
672
Chapter 25 Database Patterns
Motivating Example
The following test attempts to use Guaranteed In-line Teardown (see In-line
Teardown on page 509) to remove all the records it created:
public void testGetFlightsByOriginAirport_NoInboundFlights()
throws Exception {
// Fixture Setup
BigDecimal outboundAirport = createTestAirport("1OF");
BigDecimal inboundAirport = createTestAirport("1IF");
FlightDto expFlightDto = null;
try {
expFlightDto = createTestFlight(outboundAirport, inboundAirport);
// Exercise System
List flightsAtDestination1 =
facade.getFlightsByOriginAirport( inboundAirport);
// Verify Outcome
assertEquals( 0, flightsAtDestination1.size() );
} finally {
facade.removeFlight( expFlightDto.getFlightNumber() );
facade.removeAirport( outboundAirport );
facade.removeAirport( inboundAirport );
}
}
This code is neither easy to write nor correct!
3
Trying to keep track of all objects
the SUT has created and then tear them down one by one in a safe manner is
very tricky.
Refactoring Notes
We can avoid most of the issues related to coordinating In-line Teardown of
multiple resources in a safe way by using Transaction Rollback Teardown and
blasting away all changes to the objects in one fell swoop. Most of the refactor-
ing work consists of deleting the existing teardown code from the fi nally clause
and inserting a call to the abortTransaction method. We also need to make the call
to beginTransaction before we do any fi xture setup, and we have to modify the
Creation Methods (page 415) to ensure that they do not commit a transaction.
To do so, we have them call a nontransactional version of the methods on the
Service Facade.
3
See In-line Teardown for an explanation of what is wrong here.
Transaction
Rollback
Teardown
673
Example: Object Transaction Rollback Teardown
Here is what the test looks like when we are done:
public void testGetFlightsByOrigin_NoInboundFlight_TRBTD()
throws Exception {
// Fixture Setup
TransactionManager.beginTransaction();
BigDecimal outboundAirport = createTestAirport("1OF");
BigDecimal inboundAirport = null;
FlightDto expectedFlightDto = null;
try {
inboundAirport = createTestAirport("1IF");
expectedFlightDto =
createTestFlight( outboundAirport, inboundAirport);
// Exercise System
List flightsAtDestination1 =
facade.getFlightsByOriginAirport(inboundAirport);
// Verify Outcome
assertEquals(0,flightsAtDestination1.size());
} finally {
TransactionManager.abortTransaction();
}
}
In this refactored test, we have replaced the multiple lines of teardown code
in the fi nally clause with a single call to abortTransaction. We still need the fi nally
clause because this example is using In-line Teardown; we could easily move this
call to the TransactionManager to the tearDown method because it is so generic.
In this example, Transaction Rollback Teardown undoes the fi xture setup
performed by the various Creation Methods we called earlier in the test. The
fi xture objects have not yet been committed to the database. Because getFlights-
FromAirport
is being called within the context of the transaction, however, it
returns the newly added but not yet committed fl ights. (That is the “C” for
“consistent” in ACID working on our behalf!)
private BigDecimal createTestAirport(String airportName)
throws FlightBookingException {
BigDecimal newAirportId =
facade._createAirport( airportName,
" Airport" + airportName,
"City" + airportName);
return newAirportId;
}
Transaction Rollback Teardown
Transaction
Rollback
Teardown
674
Chapter 25 Database Patterns
The creation method calls the nontransactional version of the facade method (an
example of a Poor Man’s Humble Object):
public BigDecimal createAirport( String airportCode,
String name,
String nearbyCity)
throws FlightBookingException{
TransactionManager.beginTransaction();
BigDecimal airportId = _createAirport(airportCode, name, nearbyCity);
TransactionManager.commitTransaction();
return airportId;
}
// private, nontransactional version for use by tests
BigDecimal _createAirport( String airportCode,
String name,
String nearbyCity)
throws DataException, InvalidArgumentException {
Airport airport =
dataAccess.createAirport(airportCode,name,nearbyCity);
logMessage("CreateFlight", airport.getCode());
return airport.getId();
}
If the method we were exercising (e.g., getFlightsFromAirport) did modify the state
of the SUT and did begin and end its own transaction, we would have to do a
similar refactoring on it as well.
Example: Database Transaction Rollback Teardown
The fi rst example hid the database from the code behind a data access layer that
returned or accepted objects. This is common practice when using the Domain
Model [PEAA] pattern for organizing the business logic. Transaction Rollback
Teardown is typically used when manipulating the database directly in our ap-
plication logic (a style known as a Transaction Script [PEAA]). The following
example illustrates this approach using .NET row sets (or something similar):
[TestFixture]
public class TransactionRollbackTearDownTest
{
private SqlConnection _Connection;
private SqlTransaction _Transaction;
public TransactionRollbackTearDownTest()
{
}
[SetUp]
Transaction
Rollback
Teardown
675
public void Setup()
{
string dbConnectionString = ConfigurationSettings.
AppSettings.Get("DbConnectionString");
_Connection = new SqlConnection(dbConnectionString);
_Connection.Open();
_Transaction = _Connection.BeginTransaction();
}
[TearDown]
public void TearDown()
{
_Transaction.Rollback();
_Connection.Close();
// Avoid NUnit "instance behavior" bug
_Transaction = null;
_Connection = null;
}
[Test]
public void AnNUnitTest()
{
const string C_INSERT_SQL =
"INSERT INTO Invoice(Amount, Tax, CustomerId)" +
" VALUES({0}, {1}, {2})";
SqlCommand cmd = _Connection.CreateCommand();
cmd.Transaction = _Transaction;
cmd.CommandText = string.Format(
C_INSERT_SQL,
new object[] {"100.00", "7.00", 2001});
// Exercise SUT
cmd.ExecuteNonQuery();
// Verify result
// etc.
}
}
}
This example uses Implicit Setup (page 424) to establish the connection and
start the transaction. After the Test Method (page 348) has run, it uses Implicit
Teardown (page 516) to roll back the transaction and close the connection. We
assign null to the instance variables because NUnit does not create a separate
Testcase Object (page 382) for each Test Method, unlike most other members of
xUnit. See the sidebar “There’s Always an Exception” on page 384 for details.
Transaction Rollback Teardown
Transaction
Rollback
Teardown
This page intentionally left blank
677
Chapter 26
Design-for-Testability
Patterns
Patterns in This Chapter
Dependency Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Dependency Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Humble Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Test Hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Design-for-
Testability
Patterns