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.
--
Kristian
I'm asking because it is mentioned in the JUnit FAQ, and discussed in
[1], although the article does not cover private classes, only fields
and methods/constructors.
