Java Reference
In-Depth Information
private void
setupDataSet(Method method) {
DataSets dataSetAnnotation = method.getAnnotation(DataSets.class);
if
( dataSetAnnotation ==
null
) {
return
;
}
String dataSetName = dataSetAnnotation.setUpDataSet();
if
( ! dataSetName.equals("") ) {
try
{
IDataSet dataSet = getReplacedDataSet(dataSetName, id);
DatabaseOperation.CLEAN_INSERT.execute(dbunitConnection,
dataSet);
}
catch
(Exception e) {
throw new
RuntimeException( "exception inserting dataset " +
dataSetName, e );
}
}
}
E
F
private void
assertDataSet(Method method) {
DataSets dataSetAnnotation =
method.getAnnotation(DataSets.
class
);
if
( dataSetAnnotation ==
null
) {
return;
}
String dataSetName = dataSetAnnotation.assertDataSet();
if
( ! dataSetName.equals("") ) {
try
{
IDataSet expectedDataSet = getReplacedDataSet(dataSetName, id );
IDataSet actualDataSet = dbunitConnection.createDataSet();
Assertion.assertEquals( expectedDataSet, actualDataSet );
}
catch
(Exception e) {
throw new
RuntimeException( "exception asserting dataset " +
dataSetName, e );
}
}
}
}
}
The dirty work is done by
DataSetsTemplateRunner
B
, a static inner class.
Abstract-
DbUnitTemplateTestCase
itself does almost nothing other than using
@RunWith
to
drive the test.
The variable
id
C
can't be passed around in annotations, because it can have
dynamic values (like in
testAddUser()
), and annotations can receive only literals
(because they're defined at compile time), so it must be shared among test cases.
Such an approach might annoy purists, but keeping state in tests is not only accept-
able in some cases but often is the best approach for a given problem. The state
(
id
) in this case is passed around only to solve an issue caused by the way the tests
are executed.
The template method
invokeTestMethod()
D
defines the three steps of the work-
flow described earlier. First, the annotation is read
E
and the dataset is used only if
the annotation value isn't an empty string
F
.
