Testing database access - JUnit in Action - page 345

(whose wrong order is the whole purpose of the example), we wrapped the dataset in
a SortedDataSet D , which returns a new dataset with the tables sorted by the order
in which its columns were defined in the database. In this example, it would sort first
by ID , which is the first column in the CREATE TABLE statement. If any two or more
lines had the same ID (which isn't the case here, because ID is the primary key), then
it would sort them by username (the second column), first_name (third column),
and so on.

U SING A DTD
You can explicitly define the database structure (instead of letting DbUnit implicitly
“guess” it when it reads the XML first line) in a DTD and add that DTD to the dataset
header, as shown in listings 17.16 and 17.17.

Listing 17.16 New version of user-reverted.xml, with DTD declaration

<?xml version="1.0"?>
<!DOCTYPE dataset SYSTEM "target/test-classes/user.dtd">
<dataset>
<users id="2" username="TheStranger"/>
<users id="1" username="ElDuderino"
first_name="Jeffrey" last_name="Lebowsky" />
</dataset>

Listing 17.17 user.dtd

<!ELEMENT dataset (users*)>
<!ATTLIST users
id CDATA #REQUIRED
username CDATA #REQUIRED
first_name CDATA #REQUIRED
last_name CDATA #REQUIRED
>
Notice the odd location (target/test-classes/) of the user.dtd file; that's the relative
directory where our test artifacts are compiled. Unfortunately, DbUnit supports only
physical locations, so the DTD path must be relative to the project's root directory or
an absolute path in the filesystem. Ideally, DbUnit should support looking up the
DTD s in the classpath.
Once user-reverted.xml is changed, the method testNULL() can be run again
(without any change) and will succeed.
Both approaches have their advantages and disadvantages. Using a DTD adds more
validation to the datasets (which can prevent other errors), at the cost of a more com-
plicated initial setup (creating the DTD , making sure it's in the right place, and so on).
On the other hand, using [NULL] makes the datasets clearer, because its presence
explicitly indicates that a value is NULL . It also has a setup cost, but if you're already
using a ReplacementDataSet , that cost is minimal (just one more line of code).
Hence, the decision depends more on the project context and personal preferences
than on the technical merits of the approach per se.