Daniel John Debrunner wrote:
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).
There is a practical benefit of using jars instead of classes when
running the tests on remote hosts. Instead of copying thousands of small
files, you copy a handful of jars.
A little scripting on your own part can solve this easily of course, so
I guess this boils down to almost nothing.
Another proposal, which *I think* allow us to keep things as they are
and generate a separate jar file for unit tests requiring
package-private access:
Use the non-standard option -Xbootclasspath.
By specifying the jars on the boot classpath, the sealing protection
will be overridden and the tests can be run. We can keep the existing
tests as they are, and only use this option when running the
"package-private unit tests". This approach also require two (currently
three) steps to run all tests, but we won't have to change the existing
jars. The unit tests can then also be run with distribution jars if
anyone should wish to do that, and with both sane and insane builds.
Does anyone see any showstoppers for this approach?
I tested a small sample with Sun VMs. Does it work for VMs from other
vendors?
--
Kristian
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.
