Organize Java Unit Tests

Please it's not a Usenet discussion, so keep the subject general (no "because I am using XYZ I prefer to...") or this will end up in a bloody war! Users following these simple rules should be able to use the most features of JavaUnit without having the mess. (VladimirBossicard)

Proposed organization:

separate tests from production code (two separate trees)
one (or more) test class per code class (Sometimes there are good reasons from breaking out some of the tests for a code class.)
test classes in the same package as the code classes
one TestSuite per package (Sometimes more, you might want to have a separate test suite that tests persistence with the actual database, for example.)
one TestAll? that includes all TestSuites

OrganizingTestCases

Suggestions from NatPryce

Name test classes in a way that can be easily detected with reflection

For example, if you use CamelCase for class names (as is the Java convention), name your test classes after the tested class, with the prefix "Test_". E.g. the class DatabaseConnector would be tested by the class Test_DatabaseConnector.

A naming convention like this makes it easy to distinguish test classes from functional classes, both visually and mechanically. The latter is useful when you...

Use reflection to create TestSuites

If you do not CodeUnitTestFirst, it's easy to forget to add a test case to a test suite. (You may be retro-fitting tests to some code you have inherited, for example). Furthermore, building a test suite by hand is repetitive, boring, work -- that's the kind of work the computer should be doing, not the programmer! Therefore, use reflection to automatically build the test suite for a test class. The latest version of JavaUnit can do this for individual test classes, but does not help you construct a single TestAll class for your entire system. Therefore...

Build test hierarchies automatically

I have a generic SystemTest class that can find all the unit tests on the classpath and organises them into a tree of test suites organised by package. It does this by recursively searching for class files that start with my naming convention for tests ("Test_") and are not inner classes (the file name does not contain "$"). This ensures that my test suite contains all tests for all packages with no extra work on my part. It also means that I can have...

: Instead of relying on MagicFilenames?, wouldn't it be better to define a MarkerInterface which all your test classes implement and use that to decide whether a class belongs to a test suite or not? -- IvesAerts
: If you have to check whether a class implements an interface then you to load every class to check whether its a test. It is much faster to scan filenames in directories than to dynamically load and link class files. Therefore I prefer using MagicFilenames?. --NatPryce

No explicit per-package test suites

It's boring to keep a per-package test suite in sync with the tests in the package. Therefore, per-package suites should be generated automatically (see above).

Many of us working in VisualAge tend to have separate packages for test cases, because you can't split a package across projects and we can't be bothered to write something to strip out the test cases for production.

Especially in VisualAge, create package X.test to hold tests for package X.

Test classes in the same package as the code classes ? Is there a reason why it is good to follow this rule, when all we want to test in unit tests are public interfaces.? (Rahul Salota)

Not if everything you test is public and you don't need to instrument your production code for testing.

JavaUnitBestPractices