Continuous Testing - Continuous Integration - page 156

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

protected String getDBUnitDataSetFileForSetUp() {
return "dbunit-project-seed.xml";
}
}

Now you have one excellent test case, making it difficult for anyone
to complain that they can't test this application in a repeatable manner.

Limit Test Cases to One Assert

During the drive of development with tight schedules and impending
happy hours, it's tempting to try and fit everything into a test case. This
haphazardness tends to lead to an abundance of assert methods ending
up in one test case. For example, the code in Listing 6-25 attempts to
verify the behavior of HierarchyBuilder 's buildHierarchy method
as well as the behavior of the Hierarchy object in one test case.

LISTING 6-25 A Test Case with Too Many Asserts

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

Note that there are three assert methods in Listing 6-25. This is a
valid JUnit test case; there is nothing prohibiting the inclusion of mul-
tiple asserts in a test case. The problem with this practice, however, is
that JUnit is built to be fast-failing. If the first assert fails, the whole
test case is abandoned from the point of failure. This means that the
next two asserts aren't run during that test run.