Meszaros G. xUnit Test Patterns Refactoring Test Code
Подождите немного. Документ загружается.
658
Chapter 25 Database Patterns
One disadvantage of using Remoted Stored Procedure Tests is that they will
likely cause the test suite to run more slowly because the tests require the database
to be available and populated with data. The tests for the stored procedures can
be put into a separate Subset Suite (see Named Test Suite on page 592) so that
they need not be run with all the in-memory tests. This can signifi cantly speed up
test execution, thereby avoiding Slow Tests (page 253).
Remoted Stored Procedure Tests also come in handy when logic written
in our programming language of choice already has unit tests and we need to
move that logic into the database. By using a Remoted Stored Procedure Test,
we can avoid rewriting the tests in a different programming language and Test
Automation Framework (page 298), which can in turn save time and money.
This pattern also enables us to avoid any translation errors when recoding the
logic, so we can be sure the recoded logic really does produce the same results.
Motivating Example
Here is an example of a stored procedure written in PLSQL:
CREATE OR REPLACE PROCEDURE calc_secs_between (
date1 IN DATE,
date2 IN DATE,
secs OUT NUMBER
)
IS
BEGIN
secs := (date2 - date1) * 24 * 60 * 60;
END;
/
This sample was taken from the examples that come with the utPLSQL tool. In real
life we might not bother testing this code because it is so simple (but then again,
maybe not?) but it will work just fi ne to illustrate how we could go about testing it.
Refactoring Notes
This example doesn’t deal so much with refactoring as with adding a missing test.
Let’s fi nd a way to write one. We will see what is involved by using the two main
variants: In-Database Stored Procedure Test and Remote Stored Procedure Test.
Example: In-Database Stored Procedure Test
This example uses utPLSQL, the xUnit family member for PLSQL, to automate
tests that run inside the database:
Stored
Procedure
Test
659
CREATE OR REPLACE PACKAGE BODY ut_calc_secs_between
IS
PROCEDURE ut_setup
IS
BEGIN
NULL;
END;
PROCEDURE ut_teardown
IS
BEGIN
NULL;
END;
-- For each program to test...
PROCEDURE ut_CALC_SECS_BETWEEN
IS
secs PLS_INTEGER;
BEGIN
CALC_SECS_BETWEEN (
DATE1 => SYSDATE
'
DATE2 => SYSDATE
'
SECS => secs
);
utAssert.eq (
'Same dates',
secs,
0
);
END ut_CALC_SECS_BETWEEN;
END ut_calc_secs_between;
/
This test uses many of the familiar xUnit patterns. It is one of several tests we
would normally write for this stored procedure—one test for each possible
scenario. (This sample was taken from the examples that come with the utPLSQL
tool. Not being a PLSQL programmer, I did not want to mess with the formatting
in case it mattered!)
Example: Remoted Stored Procedure Test
To test this stored procedure in our normal programming and test execution
environment, we must fi rst fi nd or create a Remote Proxy for it in our unit-testing
environment of choice. Then we can write our unit tests in the usual manner.
Stored Procedure Test
Stored
Procedure
Test
660
Chapter 25 Database Patterns
The following test uses JUnit to automate tests that run outside the database and
call our PLSQL stored procedure remotely:
public class StoredProcedureTest extends TestCase {
public void testCalcSecsBetween_SameTime() {
// Setup
TimeCalculatorProxy SUT = new TimeCalculatorProxy();
Calendar cal = new GregorianCalendar();
long now = cal.getTimeInMillis();
// Exercise
long timeDifference = SUT.calc_secs_between(now,now);
// Verify
assertEquals( 0, timeDifference );
}
}
We have reduced the complexity of the original test to a simple test of a function
by hiding the JdbcOdbcCallableStatement behind a Service Facade. Looking at this
example, it is diffi cult to tell that we are not testing a Java method. We would prob-
ably have additional Expected Exception Tests (see Test Method on page 348)
to verify failed connections and other problems.
Stored
Procedure
Test
661
Table Truncation Teardown
How do we tear down the Test Fixture when it is in a relational database?
We truncate the tables modifi ed during the test to tear down the fi xture.
A large part of making tests repeatable and robust is ensuring that the test fi xture
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 pos-
sible circumstances is challenging and time-consuming. It involves understand-
ing what could be left over for each possible outcome of the test and writing
code to deal with that possibility. 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).
When testing a system that uses a relational database, we can take advantage
of the database’s capabilities by using the
TRUNCATE command to remove all data
from a table we have modifi ed.
How It Works
When we no longer need a persistent fi xture, we issue a TRUNCATE command for
each table in the fi xture. It blasts all data out of the tables very effi ciently with
no side effects (e.g., triggers).
Data
Setup
Exercise
Verify
Teardown
SUT
Fixture
Truncate
Insert
Update
Exercise
Data
Setup
Exercise
Verify
Teardown
SUT
Fixture
Truncate
Insert
Update
Exercise
Table Truncation Teardown
Table
Truncation
Teardown
662
Chapter 25 Database Patterns
When to Use It
We often turn to Table Truncation Teardown when we are using a Persistent
Fresh Fixture (see Fresh Fixture on page 311) strategy with an SUT that includes
a database. It is rarely our fi rst choice, however. That distinction goes to Transac-
tion Rollback Teardown (page 668). Nevertheless, Table Truncation Teardown
is a better choice for use with a Shared Fixture (page 317), as this type of fi xture,
by defi nition, outlives any one test. By contrast, using Transaction Rollback
Teardown with a Shared Fixture would require a very long-running transaction.
While not impossible, such a long-lived transaction is troublesome.
Before we can use Table Truncation Teardown, we must satisfy a couple of
criteria. The fi rst requirement is that we really want all data in the affected tables
removed. The second requirement is that each Test Runner (page 377) has its
own Database Sandbox (page 650). Table Truncation Teardown will not work if
we are using a Database Partitioning Scheme (see Database Sandbox) to isolate
users or tests from one another. It is ideally suited for use with a DB Schema per
Test Runner (see Database Sandbox), especially when we are implementing an
Immutable Shared Fixture (see Shared Fixture) as a separate shared schema in the
database. This allows us to blast away all the Fresh Fixture data in our own
Database Sandbox without affecting the Immutable Shared Fixture.
If we are not using a transactional database, the closest approximation is
Automated Teardown (page 503), which deletes only those records that were
created by the test. Automated Teardown does not depend on the database
transactions to do the work for it, but it does involve more development work
on our part. We can also avoid the need to do teardown entirely by using Delta
Assertions (page 485).
Implementation Notes
Besides the usual “Where do we put the teardown code?” decision, implementa-
tion of Table Truncation Teardown needs to deal with the following questions:
• How do we actually delete the data—that is, which database commands
do we use?
• How do we deal with foreign key constraints and triggers?
• How do we ensure consistency when we are using an object-relational
mapping (ORM)?
Some databases support the TRUNCATE command directly. Where this is the case, the
obvious choice is to use this command. Oracle, for example, supports TRUNCATE.
Table
Truncation
Teardown
663
Otherwise, we may have to use a DELETE * FROM table-name command instead. The TRUN-
CATE
or DELETE commands can be issued using In-line Teardown (page 509—called
from within each Test Method; see page 348) or Implicit Teardown (page 516—
called from the tearDown method). Some people prefer to use this command with
Lazy Teardown because it ensures that the tables are empty at the beginning of
the test in cases where those tables would be affected by extraneous data.
Database foreign key constraints can be a problem for Table Truncation
Teardown if our database does not offer something similar to Oracle’s ON
DELETE CASCADE
option. In Oracle, if the command to truncate a table includes the
ON DELETE CASCADE option, then rows dependent on the truncated table rows are
deleted as well. If our database does not cascade deletes, we must ensure that
the tables are truncated in the order required by the schema. Schema changes
can invalidate this order, resulting in failures in the teardown code. Fortunately,
such failures are easy to detect: A test error tells us that our teardown needs
adjusting. Correction is fairly straightforward—typically, we just need to reor-
der the TRUNCATE commands. We could, of course, come up with a way to issue
the TRUNCATE commands in the correct order dynamically based on the dependen-
cies between the tables. Usually, however, it is enough to encapsulate this trun-
cation logic behind a Test Utility Method (page 599).
If we want to avoid the side effects of triggers and other complications for
databases where TRUNCATE is not supported, we can disable the constraints and/or
triggers for the duration of the test. We should take this step only if other tests
exercise the SUT with the constraints and triggers in place.
If we are using an ORM layer such as Toplink, (N)Hibernate, or EJB 3.0,
we may need to force the ORM to clear its cache of objects already read from
the database so that subsequent object lookups do not fi nd the recently deleted
objects. For example, NHibernate provides the ClearAllCaches method on the
TransactionManager for this purpose.
Variation: Lazy Teardown
A teardown technique that works with only a few styles of Shared Fixtures is
Lazy Teardown. With this pattern, the fi xture must be destroyable at an arbitrary
point in time. Thus we cannot depend on “remembering” what needs to be torn
down; it must be obvious without any “memory.” Table Truncation Teardown
fi ts the bill because how we perform teardown is exactly the same whenever we
choose to do it. We simply issue the table truncation commands during fi xture
setup before setting up the new fi xture.
Table
Truncation
Teardown
Table Truncation Teardown
664
Chapter 25 Database Patterns
Motivating Example
The following test attempts to use Guaranteed In-line Teardown (see In-line
Teardown) to remove all the records it created:
[Test]
public void TestGetFlightsByOrigin_NoInboundFlights()
{
// Fixture Setup
long OutboundAirport = CreateTestAirport("1OF");
long InboundAirport = CreateTestAirport("1IF");
FlightDto ExpFlightDto = null;
try
{
ExpFlightDto =
CreateTestFlight(OutboundAirport, InboundAirport);
// Exercise System
IList FlightsAtDestination1 =
Facade.GetFlightsByOriginAirport( InboundAirport);
// Verify Outcome
Assert.AreEqual( 0, FlightsAtDestination1.Count );
}
finally
{
Facade.RemoveFlight( ExpFlightDto.FlightNumber );
Facade.RemoveAirport( OutboundAirport );
Facade.RemoveAirport( InboundAirport );
}
}
This code is neither easy to write nor correct!
1
Trying to keep track of the many
objects the SUT has created and then tear them down one by one in a safe man-
ner is very tricky.
Refactoring Notes
We can avoid most of the issues with coordinating In-line Teardown of mul-
tiple resources in a safe way by using Table Truncation Teardown and blasting
away all the airports in one fell swoop.
2
Most of the refactoring work involves
deleting the existing teardown code from the fi nally clause and inserting a call to
cleanDatabase. We then implement this method using the truncation commands.
1
See In-line Teardown for an explanation of what is wrong here.
2
This assumes that we start with no airports and want to end with no airports. If we
want to delete just these specifi c airports, we cannot use
Table Truncation Teardown.
Table
Truncation
Teardown
665
Example: Table Truncation (Delegated) Teardown Test
This is what the test looks like when we are done:
public void TestGetFlightsByOrigin_NoInboundFlight_TTTD()
{
// Fixture Setup
long OutboundAirport = CreateTestAirport("1OF");
long InboundAirport = 0;
FlightDto ExpectedFlightDto = null;
try
{
InboundAirport = CreateTestAirport("1IF");
ExpectedFlightDto =
CreateTestFlight( OutboundAirport,InboundAirport);
// Exercise System
IList FlightsAtDestination1 =
Facade.GetFlightsByOriginAirport(InboundAirport);
// Verify Outcome
Assert.AreEqual(0,FlightsAtDestination1.Count);
}
finally
{
CleanDatabase();
}
}
This example uses Delegated Teardown (see In-line Teardown) to keep the
teardown code visible. Normally, however, we would use Implicit Teardown
by putting this logic into the tearDown method. The try/catch ensures that clean-
Database
is run but it does not ensure that a failure inside cleanDatabase will not
prevent the teardown from completing.
Example: Lazy Teardown Test
Here is the same example converted to use Lazy Teardown:
[Test]
public void TestGetFlightsByOrigin_NoInboundFlight_LTD()
{
// Lazy Teardown
CleanDatabase();
// Fixture Setup
long OutboundAirport = CreateTestAirport("1OF");
long InboundAirport = 0;
FlightDto ExpectedFlightDto = null;
InboundAirport = CreateTestAirport("1IF");
ExpectedFlightDto =
CreateTestFlight( OutboundAirport, InboundAirport);
// Exercise System
Table
Truncation
Teardown
Table Truncation Teardown
666
Chapter 25 Database Patterns
IList FlightsAtDestination1 =
Facade.GetFlightsByOriginAirport(InboundAirport);
// Verify Outcome
Assert.AreEqual(0,FlightsAtDestination1.Count);
}
By moving the call to cleanDatabase to the front of the Test Method, we ensure
that the database is in the state we expect it. This code cleans up whatever the
last test did, regardless of whether that test provided proper teardown. It also
takes care of anything added to the relevant tables since the last test was run. It
has the added benefi t of eliminating the need for the try/fi nally construct, thereby
making the test simpler and easier to understand.
Example: Table Truncation Teardown Using SQL
This implementation of the cleanDatabase method uses SQL statements constructed
within the code:
public static void CleanDatabase() {
string[] tablesToTruncate =
new string[] {"Airport","City","Airline_Cd","Flight"};
IDbConnection conn = getCurrentConnection();
IDbTransaction txn = conn.BeginTransaction();
try {
foreach (string eachTableToTruncate in tablesToTruncate)
{
TruncateTable(txn, eachTableToTruncate);
}
txn.Commit();
conn.Close();
} catch (Exception e) {
txn.Rollback();
} finally {
conn.Close();
}
}
private static void TruncateTable( IDbTransaction txn,
string tableName)
{
const string C_DELETE_SQL = "DELETE FROM {0}";
IDbCommand cmd = txn.Connection.CreateCommand();
cmd.Transaction = txn;
cmd.CommandText = string.Format(C_DELETE_SQL, tableName);
cmd.ExecuteNonQuery();
}
Table
Truncation
Teardown
667
Because we are using SQL Server as the database, we had to implement our own
TruncateTable method that issues a Delete * from ... SQL command. We would not
have to take this step if our database implemented TRUNCATE directly.
Example: Table Truncation Teardown Using ORM
Here is the implementation of the cleanDatabase method using NHibernate, an
ORM layer:
public static void CleanDatabase() {
ISession session =
TransactionManager.Instance.CurrentSession;
TransactionManager.Instance.BeginTransaction();
try {
// We need to delete only the root classes because
// cascade rules will delete all related child entities
session.Delete("from Airport");
session.Delete("from City");
session.Flush();
TransactionManager.Instance.Commit();
} catch (Exception e) {
Console.Write(e);
throw e;
} finally {
TransactionManager.Instance.CloseSession();
}
}
When using an ORM, we read, write, and delete domain objects; the tool deter-
mines which underlying tables they map to and takes the appropriate actions.
Because we have chosen to make City and Airport “root” (parent) objects, any
subordinate (child) objects such as the Flights are deleted automatically when
the root is deleted. This approach further decouples us from the details of the
table implementations.
Table Truncation Teardown
Table
Truncation
Teardown