Information Technology Reference
In-Depth Information
okay, though—mistakes happen and mistakes can be fixed and, ideally,
learned from. Making the same mistake twice, though, is quite
unforgivable.
Some use the term defect-driven development when referring to
writing tests for defects; however, that term has always sounded rather
negative. Defects don't drive development— preventing those nasty
aberrations drives development! If anything, defects halt develop-
ment—it's the act of addressing them and then ensuring they don't
come back that keeps the wheels moving. Here is a proven strategy for
guaranteeing that once a defect is found, it doesn't come back.
When a defect is discovered, find and isolate the offending code. If
the project has a healthy number of test cases, it's probably a good bet
that the defect has occurred in some portion of untested code (maybe an
unconsidered path)—and most likely in the interaction of components.
For example, Listing 6-12 presents a find method in a Hibernate
DAO class, which attempts to retrieve a word from a database.
LISTING 6-12
DAO with a Defect
public IWord findWord(String word) throws FindException{
Session sess = null;
try{
sess = WordDAOImpl.sessFactory.getHibernateSession();
final Query qry = sess.getNamedQuery("word.finder.bySpelling");
qry.setString("spelling", word);
final List lst = qry.list();
final IWord wrd = (IWord)lst.get(0);
sess.close();
return wrd;
}catch(Throwable thr){
try{sess.close();}catch(Exception e){}
throw new FindException("Exception while finding word: "
+ word + " "+ thr.getMessage(), thr);
}
}
This class has been reasonably tested in a series of component-
level tests that utilize DbUnit. These tests verify the basic CRUD (cre-
ate, read, update, and delete) operations. For example, Listing 6-13
shows a test for the find method.
Search WWH ::




Custom Search