A small debate has cropped up in the threads on the existing and proposed
Commons packages about where to put the test classes.
There are two basic options:
1. Place the test cases in their own directory, independent of the classes
they are testing (e.g., /src/**.java, /test/**.java)
2. Place the test cases in with the rest of the source, and use a naming
convention to distinguish test from non-test classes (e.g,
/src/**/Test*.java or /src/**/*Test.java, etc.) The naming convention makes
it easy to filter the test classes out of production JARs, JavaDocs, etc.,
as they do in my build.xml examples.
As you can probably guess from my proposals, I'm a fan of the later (one
source directory) approach.
Why?
a) The build script and directory organization is simplier.
b) The tests go where the "real classes" go. (The tests are *real classes*,
they're just not used in production.) And by "go", I don't just mean that
they are placed in the same directory tree, but rather that when you build
one you build the other, when you copy one you copy the other, etc.
c) It's easy to see which classes are being tested and which are not, which
in turn encourages more testing. (To counter Peter's example, in my
experience this has encouraged more complete testing.)
I guess it's just the XP zealot in me, but the "test, code, test" cycle
seems much more natural if it's all coming from the same place in the
directory tree.
So, I lean toward the "single tree" approach, but I'm not married to it
either. Nor am I particuarly concerned that everything in commons does it
one way or the other (as long as a single component doesn't do both), but I
thought that if we we're going to make it a guideline one way or the other,
I'd state my case.
Thoughts?
- Rod
