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.
Probably option c) is a bit too complicated to manage and does not bring
any special benefit against a) or b).
Should I create a separate jira for this or it could be done as a part
of DERBY-2031?
Any other suggestions?
Cheers
Julo
Kristian Waagan wrote:
John Embretsen wrote:
Julius Stroffek wrote:
Hi All,
I deal with a problem of testing a functionality of private classes.
<snip>
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.
<snip>
Just wondering, does anyone know if using reflection to bypass the
Java access protection (as Kristian mentioned in the above mentioned
thread) is completely out of the question?
Hi John,
The subject of the original mail might be a bit inaccurate, as my
interpretation is that what we want to achieve is to write unit tests
for package-private classes (no modifier in front of the class keyword).
This is different from (inner) private classes.
I think using reflection to test private *methods* should be avoided
if possible. The test code gets a lot bigger and harder to understand.
If you really need to test private methods, I guess using a static
nested class would be just as good.
I do not know the state of the tools providing the kind of
functionality you mention, so it might be worth checking out anyway.
Last, I would really appreciate a way to write unit tests for
package-private classes. I think some good ideas have been put forth
in this mail-thread, and hope the community will be able to reach
consensus for an acceptable solution.
