Continuous Testing - Continuous Integration - page 148

behavior. The defect-driven example would work by now, and the
chances are we'd leave the test case as so. But that test case doesn't
provide too much value now. We need to assert that when an invalid
word is passed into the findWord method, null is returned. We also
need to assert than an Exception isn't thrown. The updated test case is
shown in Listing 6-17.

LISTING 6-17 Updated Test Case Verifying the Fix

public void testFindInvalidWord() throws Exception{
final WordDAOImpl dao = new WordDAOImpl();
try{
final IWord wrd = dao.findWord("fetit");
TestCase.assertNull("Should have received back a null object", wrd);
}catch(FindException ex){
TestCase.fail("This should not throw an exception");
}
}

Now we're done and we've accomplished two things. First, the
defect has been corrected. Congratulations! Second, a regression test is
now in place that truly asserts the correct behavior of the fix.
Which practice should we follow: defect-driven development, or
should we call it continuous-prevention development ? They both
drive you to:

• Fix the defect
• And prevent the defect from recurring

Continuous-prevention development, however, has the tendency to
drive you to carry out a third step, which is asserting any new behavior
triggered by the defect's fix.

Make Component Tests Repeatable

Many Web applications work against databases. Databases, however,
present quite a large dependency for testing, leaving you with two
choices: Either mock out as much as possible and avoid the database
altogether for as long as possible, or pay the price and utilize the data-