db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Stroffek <Julius.Strof...@Sun.COM>
Subject Re: Testing implementation of private classes
Date Tue, 16 Jan 2007 12:10:55 GMT
Looks excellent. ;-)


Kristian Waagan wrote:
> 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?

View raw message