JUnitTips

We always put our TestCase classes in a different package. This means that you can run into access problems if you want to test methods which should really be private.

In the past we've made those methods protected, then extended the class we want to test in our test package, allowing us to access those protected methods. But this is ugly and causes confusion.

I've never understood why putting your test classes in the same package as production code is considered 'bad'. I've always placed them in the same package, and never had a problem. And as private methods ultimately have to be called by a non-private method, they are testable 'by proxy'. Am I missing something? --DarrenHobbs

Java 1.2 gives you a neat solution. If you grant your test code the java.lang.reflect.ReflectPermission? then you can call private methods.

1. Edit the java.policy file run the policytool from the JDK if you like.

I'm trying to get this working in VisualAge but, VisualAge seems to generate the java.policy file when it starts. test

--OliBye

• Put your test classes in the same java package as your actual code but in a parallel directory structure. So src/code is production code whilst src/test contains testing code. Fairly obvious in hindsight.
• Be wary of the JUnit howtos that are available online. If you're using the latest version of JUnit (3.8.1) then a lot of the boilerplate code isn't needed anymore.
• Create your own test utility classes (along the lines of JUnit Addons http://junit-addons.sourceforge.net/) containing things like assertions that are re-used in your code.
• Use the AbstractTest? http://c2.com/cgi/wiki?AbstractTest pattern
• ...