Julius.Stroffek wrote:
Hi All,
I'll try to divide the problem into two parts:
1.) Writing tests.
I think that nobody argued that we should use something really different
than the parallel source tree.
2.) Executing tests. There are more possibilities on this.
a) executing the test against the classpath.
b) creating the separate derby jar file for testing private classes.
c) creating the separate jar with tests' implementation and creating
the nearly same jar files as the derby product jars but which will not
be sealed.
What's the benefit of running unit tests against jar files? For
functional tests I see the benefit, it is testing the user api using
artifacts the user is expected to have on the classpath. However for
unit tests I can't see what bugs would be found by testing against
classes that are in a "fake" jar (assuming the unit tests are run
against classes as well).
So I see b) and c) as being the same really, manufacturing some fake jar
(and for b it's more than derby.jar, may want to unit test network code
for example) for no benefit. As an alternative I think the unit testing
could easily be setup as a optional step in the build process. There
could be an additional target in top level build.xml file that ran the
unit tests against the classes and those that wanted could include it in
their build process (e.g. a target all_with_unit_tests).
Dam.
