Julius Stroffek wrote:
Hi All,
I deal with a problem of testing a functionality of private classes. I
work on converting a derbynet/testProtocol.java test to junit
(DERBY-2031). I think that the tendency of writing derby tests is
a) Separate the testing source code from the derby source.
b) Produce a testing jar file derbyTesting.jar which could be run
against 'any' distribution/build of derby (more or less ;-).
c) The derby distribution itself should not contain any test code.
I have created a patch for DERBY-2031 which makes all the required
private classes and functions public. I think it does not matter in this
case. However, it is not a good practice to do this in general. I needed
some functionality of DDMReader and DDMWriter and some more classes. If
these classes will be changed to public it should not matter that
anybody could create its own instance of DDMReader/Writer because the
instances used by the DRDAConnectionThread are still hidden and can not
be obtained outside the package.
Bryan pointed me at the discussion at
http://www.nabble.com/Re%3A-JUnit-unit-tests---parallel-test-three--p5711307.html
where Kristian discussed this couple months ago. I talked to Kristian
and he told me that the problem was not solved at that time.
I have only two solutions to this:
1.) Change the visibility of required classes to public.
2.) Maintain the parallel package tree (suggested by Krisitian) with
implementation of tests of private classes. The tests will be in a same
package but different source directory. The build system will manage to
place the tests to derbyTesting.jar only. According the docs, the class
loader should choose the correct jar file to load a class (if the jar
sealing is turned off). I'll check this.
Since changing the visibility of code is not desired I see the option 2
as the preferred one. Are there any other possibilities? What are your
opinions?
Both solutions are affecting the visibility of code. Option 2) is
removing the option of sealing *all* the classes in that package, thus
defeating any package access protection.
If the testing really is just for a specific class, then it does not
matter that the class is in one of the derby "product" jars. So a couple
of variants of 2) are:
- test only when running tests from the classpath
- archive the class into another jar where it is not sealed and run
the tests against with that jar in the classpath and none of the derby
"product" jars.
Dan.
