Vincent
Thank you for your response.
"1- make your methods protected instead of private. They will be accessible
by your test class as long as this test class is in the same package ! I
think it is not that bad since the method is still not public."
I currently make the methods package friendly and place tests classes in the
same package. However, from the security perspective, it is quite possible
for a person to add another class to a package and get some interesting
behavior through these exposed methods. There is something called "package
sealing" in JARs, but I am not
sure what protection that offers, if any. From a point of principle, it
seems better to keep everything as private as possible.
"2- now, if you really want to keep the method private, you always have the
possibility to unit test private class (I'm not sure how, but this is done
by several test famework - You can check JUnitX which does it"
Thanks for the pointer to JUnitX - it does indeed offer the ability to test
private methods using a proxy class. There is also a
java.lang.reflect.ReflectPermission that turns off access checks. However,
in this latter case, I am unsure as to whether it is possible, or wise, to
fool the compiler into compiling the test classes calling upon private
methods in another class. Perhaps JUnitX is using this reflection permission
to facilitate the test proxy calling into the private methods of other
classes?
Tom
