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
'java/testing/org/apache/derby'?
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.
Regards,
--
Kristian
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,
|