2

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 .

James Roeiter
  • 861
  • 1
  • 9
  • 23
  • 1
    The preferred approach is a parallel source tree with JUnit, avoiding reflection entirely. Anything "internal" that you want to test should just be package-private instead of fully private. – Louis Wasserman Apr 21 '12 at 00:44
  • Great ! I come from the .NET world and less familiar with how its being done correctly , I want to do it well the first time , can you please post your technique ? – James Roeiter Apr 21 '12 at 00:48
  • :) 25% is low , but I am a new user and barely asked questions... Believe me that I would more than want to accept a good answer .. I am a polite person with good manners. Both in real and both on-line. – James Roeiter Apr 21 '12 at 00:51

2 Answers2

1

As I understand Louis Wasserman's response you have a file structure that looks like

src/production/mypackage/MyClass.java

src/junit/mypackage/MyClassTest.java

Then src/production/mypackage/MyClass.java looks like

class MyClass
{
      void start ( ) { ... }
      void stop ( ) { .... }

      class InnerClass1 { ... } 
      class InnerClass2 { ... }\
      ...
      class InnerClass50 { ... }
}

Since MyClassTest and MyClass are in the same package mypackage.MyClass.InnerClass1...50 can be tested from MyClass test.

Make sure that MyClass does not depend on MyClassTest for anything. For production, you can compile everything in the production directory (skipping junit tests entireley). For testing compile both directories.

emory
  • 10,725
  • 2
  • 30
  • 58
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.

Community
  • 1
  • 1
sparc_spread
  • 10,643
  • 11
  • 45
  • 59