Continuous Testing - Continuous Integration - page 150

public void testFindVerifyDefinition() throws Exception{
final WordDAOImpl dao = new WordDAOImpl();
final IWord wrd = dao.findWord("pugnacious");

for(Iterator iter =
wrd.getDefinitions().iterator(); iter.hasNext();){
IDefinition def = (IDefinition)iter.next();
assertEquals("Combative in nature; belligerent.",
"Combative in nature; belligerent.",
def.getDefinition());

}
}

public DefaultWordDAOImplTest(String name) {
super(name);
}
}

Note, though, that this class makes the assumption that the data-
base is located on the same machine on which the test is run. This may
be a safe assumption on the developer's workstation, but obviously this
configuration can present a challenge in CI environments.
One solution is to pull out the hard-coded connection strings and
place them into properties files. There is, however, a more effective
mechanism. If DbUnit is utilized to seed a database, you can infer that
the application itself then uses a database. If this is the case, it is a
common practice to avoid hard-coding connection information within
a code base; therefore, why not configure DbUnit to read the same file
that the application under test reads?
For example, in Hibernate applications, database connection infor-
mation is usually defined in the hibernate.cfg.xml file. You can easily
write a utility class that parses this file and obtains the proper connec-
tion information. Even better, as shown in Listing 6-20, you can rely
on Hibernate to provide the desired information.

Hibernate Configuration Utility

LISTING 6-20

public class DBUnitHibernateConfigurator {
static Configuration configuration = null;

private DBUnitHibernateConfigurator() {
super();
}

private static Configuration getConfiguration()
throws HibernateException {