Information Technology Reference
In-Depth Information
TestCase.fail("This should throw an exception");
}catch(FindException ex){
Throwable thr = ex.getOriginalException();
TestCase.assertTrue("Should be instance of " +
IndexOutOfBoundsException",
ex.getOriginalException() instanceof
IndexOutOfBoundsException);
}
}
If you run this test, it passes. Therefore, you've proven that there is
a defect. Now you can fix it.
This methodology, by the way, is slightly different than the pre-
vailing “defect-driven development” approach, which suggests writing
a
failing
test case first and then to keep running that test (while fixing
the defect) until the test stops failing. For example, the code in Listing
6-15 is a defect-driven test case.
Sample Defect-Driven Style Test Case
LISTING 6-15
public void testFindInvalidWordException() {
final WordDAOImpl dao = new WordDAOImpl();
try{
final IWord wrd = dao.findWord("fetit");
}catch (FindException e){
TestCase.fail("Didn't find word fetit");
}
}
This test case, of course, fails when first run (assuming the defect
is still present). This practice does work; however, it presents some
opportunities for refinement. Writing a test case that purposely fails at
first
present these challenges.
• It is difficult to write a failing test in this scenario that uses an
assert properly.
Because of this, asserts may not ever be added, even after the test
case doesn't fail anymore. This means the test case isn't neces-
sarily passing—it is merely not failing.
• At this point in the game, it is tricky to know how the fix will
affect behavior, so in attempting to fail the test you end up guess-
ing what the fix may be.
