Re: JUnit unit tests - parallel test three?
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,
Re: Re: JUnit unit tests - parallel test three?
On 8/8/06, Kristian Waagan [EMAIL PROTECTED] wrote: 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'? One thing we want to avoid is test code having identical package names as engine/client code. This could lead to test code accidentally ending up in the jar files and increasing footprint, and is one of the reasons why we have the test code in a separate package, org.apache.derbyTesting, from the non-test code. So, as long as your tree were amended to make derby = derbyTesting, it would probably be ok. b) Another alternative would be to add another directory in 'java', for instance 'unittesting'. I'm not entirely against this, but I think it's desirable to keep all the test code in java/testing. Hopefully, there's a way we can keep all the test code in one dir, java/testing, but keep the unit testing code separate from the functional tests. 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. Neither approach would be difficult to implement from a build perspective, although, if all the new unit tests are in their own tree, then you avoid having to workaround the complexities of building the files already in java/testing/org/apache/derbyTesting/functionTests. 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. Maybe we should just rename that package 'oldUnitTests' until they can be converted to junit tests? andrew
Re: JUnit unit tests - parallel test three?
Andrew McIntyre wrote: On 8/8/06, Kristian Waagan [EMAIL PROTECTED] wrote: 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'? One thing we want to avoid is test code having identical package names as engine/client code. This could lead to test code accidentally ending up in the jar files and increasing footprint, and is one of the reasons why we have the test code in a separate package, org.apache.derbyTesting, from the non-test code. So, as long as your tree were amended to make derby = derbyTesting, it would probably be ok. Hi Andrew, What you are telling me to avoid, is excatly what I want to do :) The reason is that I want to be able to write unit tests for package private classes. I guess this might complicate things wrt build scripts, and maybe also wrt to jar sealing. Do you know of any other means to achieve what I seek, besides from writing indirect tests using the public API, or some overly complicated approach as using reflection to bypass access restrictions? Note that I only wish to be able to write unit tests for package private classes (and more public), not private classes. -- Kristian [snip] andrew
