◆ Problem
You want to verify that your test case classes adhere to the basic syntax rules of JUnit, but many common problems cannot be caught by the compiler.
◆ Background
You have a large suite of test cases, including dozens or even hundreds of test case classes. It is virtually impossible—at least highly undesirable—to inspect all your test case classes by hand or execute each individually to uncover problems such as incorrectly overriding setUp() and tearDown(), or not providing a proper suite() method. Moreover, whenever someone changes the tests, she runs the risk of rein- troducing the kind of problem that can easily go unnoticed. You would like to run some sanity check on your tests to give you some confidence that they at least
“make sense.”
◆ Recipe
JUnit-addons provides a nifty tool to help: the TestClassValidator. The idea behind this tool is to examine the source of a test case class and highlight any potential defects in it that compilers cannot catch, such as typing setup() rather than setUp() or failing to make the suite() method class level. Listing 17.9 shows a test case class with a number of problems (or potential problems) we have high- lighted in bold print.
615 Verify your test case class syntax
public class ValidationExample extends TestCase {
public ValidationExample(String name) { super(name);
}
public Test suite() { return null;
}
public void setup() { }
public void tearDown() { }
public void atestDummy() { assertTrue( true );
} }
To execute the TestClassValidator, issue the following command.
java junitx.tool.TestClassValidator classname
For the above class, TestClassValidator provides the following report.
TestClassValidator, by Vladimir R. Bossicard
WARN > junitx.example.ValidationExample: method potentially misspelled
<setup>
ERROR> junitx.example.ValidationExample: method 'suite' must be static INFO > junitx.example.ValidationExample: method seems to be a test
<atestDummy>
The method potentially misspelled is setup(), which ought to be setUp(). This is a common source of questions on the JUnit mailing lists. The next problem is clear enough: the suite() method must be class level (static) in order for JUnit to use it to collect your tests. Finally, the method atestDummy()looks like a test:
after all, it has test in the name and makes an assertion, so you probably just slipped on the keyboard just before running your build process. The TestClass- Validator notices when you make the kind of mistake that a compiler does not catch, but that might affect your tests. It is not as good as having someone pro- gram with you, but it helps.
Listing 17.9 A test case class in need of validation
616 CHAPTER 17 Odds and ends
◆ Discussion
If you validate your test classes before executing them, you can save yourself the embarrassment of hiding a defect for weeks (months!) before finding it. The point of ongoing testing is to find defects as soon as you inject them into the code. If you mistype a test method name and that test does not execute, and that is the only test that exposes a certain defect...well, you might finally uncover the defect later—
much later. The longer you wait to uncover a defect after creating it, the more effort it takes to understand the defect and to fix it. If you are going to spend time writing tests, you want them to execute. They are not there to “look pretty.”
If you have other test case validation rules you would like to enforce with TestClassValidator, then you can subclass ClassValidator and add your own rules. If you would like to report the errors differently, you can provide your own implementation of ClassValidatorListener and listen for validation events of var- ious severities: warning, information, or error. This is another example of the commitment of JUnit-addons to simple, flexible design.
Another way to verify these kinds of coding issues is to use a style checker, such as PMD (http://pmd.sourceforge.net/) or checkstyle (http://checkstyle.sourceforge.
net/). Although one generally thinks of these tools as ways to enforce a team’s coding style, they simply verify that source code conforms to some standard, so we can certainly use them to verify that source code conforms to the demands of a framework such as JUnit. As this is not a book about coding standards, we recom- mend you visit the various web sites of these coding standards tools to see whether they might help you on your project. They have become part of the standard tool- kit for Java Open Source projects, particularly the Jakarta projects (http://
jakarta.apache.org).
Robert Wenner provided a more clever solution to the specific problem of mistyping setup() and teardown(). It is not a general-purpose solution, but if you make this mistake often enough, then you might want to try it. He recommends adding these two methods to your Base Test Case class (see recipe 3.6, “Introduce a Base Test Case”).
private final void setup() { }
private final void teardown() { }
Now in your test case class if you accidentally type setup() rather than setUp(), the compiler catches the error. Is this solution too clever? We do not think so.
617 Extract a custom assertion
If you happen to have considerable trouble with this kind of mistake—we all have our blind spots—then we think it is worth trying.
◆ Related
■ PMD (http://pmd.sourceforge.net/)
■ checkstyle (http://checkstyle.sourceforge.net/)