Q: How to organize unit testing

[Casper B]

If I have a custom library formed by a package hiarachy build over the
years, what is the usual way of organizing JUnit testing?

Placing a suite in every package which wraps test case classes is messy
and pollutes the library when deployed as a jar.

I see two possebilites, either separate the tests by the use of
preprocessor build directives (but Java has none right?) or create a
mirror of the library package structure where only the tests live. Which
is the common practice and what problems should I look out for?

Thanks in advance,
Casper

[Raymond DeCampo]

Casper B wrote:

If I have a custom library formed by a package hiarachy build over the
years, what is the usual way of organizing JUnit testing?

Placing a suite in every package which wraps test case classes is messy
and pollutes the library when deployed as a jar.

I see two possebilites, either separate the tests by the use of
preprocessor build directives (but Java has none right?) or create a
mirror of the library package structure where only the tests live. Which
is the common practice and what problems should I look out for?

Personally I prefer to keep the test classes in a separate directory one
way or another. Unless the tests depend on package visible member items
in the original classes you can keep them in a separate package.

I recommend looking into using ANT (http://ant.apache.org) for building.
ANT is capable of doing the build the way you want it (one way for the
regular classes, another for the test classes). Further, ANT has
special junit directives that make it possible to execute your JUnit
classes without having to build special suites. ANT is capable of doing
all this in a generic, parameterized fashion, meaning you can reuse the
build scripts for other projects.

HTH,
Ray

--
XML is the programmer's duct tape.

[Arne]

"Raymond DeCampo" <no****@twcny.rr.com> wrote in message
news:g4*****************@twister.nyroc.rr.com...

Casper B wrote:

If I have a custom library formed by a package hiarachy build over the
years, what is the usual way of organizing JUnit testing?

Placing a suite in every package which wraps test case classes is messy
and pollutes the library when deployed as a jar.

I see two possebilites, either separate the tests by the use of
preprocessor build directives (but Java has none right?) or create a
mirror of the library package structure where only the tests live. Which
is the common practice and what problems should I look out for?

Personally I prefer to keep the test classes in a separate directory one
way or another. Unless the tests depend on package visible member items
in the original classes you can keep them in a separate package.

I recommend looking into using ANT (http://ant.apache.org) for building.
ANT is capable of doing the build the way you want it (one way for the
regular classes, another for the test classes). Further, ANT has
special junit directives that make it possible to execute your JUnit
classes without having to build special suites. ANT is capable of doing
all this in a generic, parameterized fashion, meaning you can reuse the
build scripts for other projects.

HTH,
Ray

--

Also quite many of the IDE's out there support JUnit directly in the tool.
We've used both NetBeans and Eclipse, and they both support JUnit directly.
Netbeans separates the tests, like Ray recommends, in a package called test,
with sub-packages reflecting the package hiarachy of your classes to be
tested. Also, NetBeans uses ANT as a project- and build tool, and best of
all: it's free :-)

Arne

[Casper B]

Thanks a lot for the answer!

Casper