Continuous Testing - Continuous Integration - page 157

Once a code fix is completed and the test is rerun, the second
assert may fail, which causes a repeat of the whole fix-rerun test case
cycle. If when running the second try, the third assert fails, yet again,
the process repeats. Notice an inefficient pattern here?
A more effective practice is to try and limit one assert to each test
case. That way, rather than repeating the three-step process just
described any number of times, you can get all your failures without
intervention in one test run. For example, the code from Listing 6-25
would be refactored into three separate test cases (see Listing 6-26).

LISTING 6-26 Test Case Refactoring

public final void testBuildHierarchyStrSize() throws Exception{
Hierarchy hier = HierarchyBuilder.buildHierarchy(
"test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
assertEquals("should be 2", 2,
hier.getHierarchyClassNames().length);
}

public final void testBuildHierarchyStrNameAgain() throws Exception{
Hierarchy hier = HierarchyBuilder.buildHierarchy(
"test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
assertEquals("should be junit.framework.TestCase",
"junit.framework.TestCase",
hier.getHierarchyClassNames()[0]);
}

public final void testBuildHierarchyStrName() throws Exception{
Hierarchy hier = HierarchyBuilder.buildHierarchy(
"test.com.vanward.adana.hierarchy.HierarchyBuilderTest");
assertEquals("should be junit.framework.Assert",
"junit.framework.Assert",
hier.getHierarchyClassNames()[1]);
}

With three separate test cases, in the first test run, three failures are
reported. This way, you can limit yourself to one fix-rerun cycle. This
practice, of course, leads to a proliferation of test cases. This is why
we have the separate directory structure introduced at the beginning of
this chapter. And the number of test cases is growing at the rate of your
code, so you must be making progress!

❑❑❑❑❑❑❑❑❑