Java Reference
In-Depth Information
public void
testAddUser()
throws
Exception {
User user = newUser();
id = dao.addUser(user);
assertTrue(id>0);
}
}
Listing 17.25
user-EL.xml, dataset that uses EL syntax for tokens
<?xml version="1.0"?>
<dataset>
<users id="${id}" username="ElDuderino"
first_name="Jeffrey" last_name="Lebowsky" />
</dataset>
Now that we've covered some of the advanced techniques you can use with DbUnit,
we look next at best practices that are specific to database access testing.
17.8
Database access testing best practices
Throughout this chapter, we described in detail best practices that apply to our exam-
ples. In this final section, we present additional best practices.
17.8.1
Use one database per developer
When you run a database test case, the test can leave the database in an unknown
state. Furthermore, the actions of other users can affect the test results. One solution
to this problem is to have each developer and build machine use their own database.
If you're fortunate enough to be developing an application that can be run in dif-
ferent database products (for instance, if it uses only standard
SQL
statements or if the
SQL
is managed by an
ORM
tool), then the best approach is to use an embedded data-
base. Not only would each developer would have their own instance, but the database
access would be fast.
If the embedded database approach isn't possible, then you should try to install a
matching database in each developer's machine (many database vendors, such as Ora-
cle, provide a light version of their product, a good option for this approach).
If neither the embedded nor the light database is possible, then try to allocate
one database instance for each developer in the database server. In the worst case,
if not even that is possible (too many instances could be costly in resources or in
license fees), allocate a few instances to be used for test cases and a few others for
regular development.
17.8.2
Make sure the target database is tested
If you can implement the embedded database approach, but the final application will
be deployed in another database product, make sure the application is tested against
the target database. A reasonable approach is to let the developers use the embedded
database but have a daily or continuous build use the target database.
