db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Testing implementation of private classes
Date Mon, 15 Jan 2007 16:29:30 GMT
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.


Mime
View raw message