db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: JUnit unit tests - parallel test three?
Date Tue, 08 Aug 2006 15:02:24 GMT
Hi again,

I'm putting forth a suggestion on my own here, since I have not received 
any feedback.

a) What about mirroring the Derby source tree at 

We would then have something like this (seen from 'java/' in trunk):
|-- build*
|-- testing
|   `-- org
|       ` -- apache
|            |-- derby
|            |   |-- authentication*
|            |   |-- catalog*
|            |   ...*
|            |   |-- osgi*
|            |   `-- vti*
|            `-- derbyTesting
|                |-- functionTests*
|                `-- unitTests*
`-- tools*

b) Another alternative would be to add another directory in 'java', for 
instance 'unittesting'.

It would also be nice if someone with knowledge of the build system 
could say a few words if any of these approaches would cause major 
changes in the build.xml files.

I expect the new directory structure to only contain JUnit unit tests. 
There is a name-clash with the existing unit test functionality of the 
old harness.

I have not yet thought much about how these tests would be run as part 
of suites etc.


Kristian Waagan wrote:
> Hello,
> I want to write a unit test for 
> 'services/io/RawToBinaryFormatStream.java", using JUnit.
> I know how to write the test itself, but where should I put it?
> The directories/categories under functionTests do not seem quite right 
> to me. My first thought was to put the test under unitTests instead, but 
> that seems to contain files for the special unit test harness that we have.
> Also, say this class is made package private. Testing it indirectly 
> through other public classes/methods might be a big hassle.
> Should we consider adding a parallel source three to be used for unit 
> tests written in JUnit?
> For now I will just write my RawToBinaryFormatStream-tests as part of a 
> functional test for LOBs. In my opinion, this is not the best solution, 
> and I would like to hear what the community thinks about these issues.
> Have I overlooked better, existing ways to do this?
> Thanks,

View raw message