Question

I have a package with a single public facade , with two methods , start and stop.
Because this facade is for something like a 50+ internal/friendly classes package , I need a way to be able and test several of those inner classes directly.

I am using Eclipse and JUnit.

Reflection can be a good way , but why writing all this reflection code on my own , is there a good tool that generates wrapper public classes (like .net visual studio can ) ?

Second of all , can someone please explain how to manage a dual source tree for JUnit or refer me to a good article in that topic ?
I saw several blog posts but prefer to see if someone from here has a good explanation/reference.

and , most important — either or not to test internal classes , is not my question here , this is my design and this is how I prefer to work .
Some think you should , some think you should not , so please dont post answers such as : you should test only public thus problem solved.
I searched in stackoverflow and could not find a good thread about it.

Thank you in advance ,

James .

Answer 1

Your instinct to maintain a dual source tree is correct. Simply have two source directories, with the same directory/package structure within. Compile to similarly separate output destinations, but put everything in your classpath when you run tests. Even though the classes may be even different output directories, their identical directory/package structure will make it work. If you use Maven, this is standard. With that tool, the source directory names are src/main and src/test, and the output directories are target/classes and target/test-classes. The fact that Maven supports this out of the box shows how standard this practice is within the Java community and you should use it with confidence. (For that matter, I encourage you to use Maven, it will make your life a lot easier. You can use Maven with Eclipse and lots of people do.)

With unit tests now being inside your package, you can test all the package-protected classes you want. I disagree with people who say only test public things. In fact, no less a luminary than Cedric Beust, the author of TestNG, argues that if it can break, it should be tested, and that includes private methods. I have unit tested private methods with a little help from reflection. Package-protected stuff is of course easier to test. Regardless, I think it’s a religious argument to say that only public things should be tested.