On Mon, 30 Jul 2001 14:29:03 -0700, William Pietri
>Lately I've been wondering how other people organize their tests with JUnit.
>It's been my habit to bend the Java package mechanism to my need; my
>testing classes are all in the same package as the classes they test. Any
>method I want to test (which is most of them) I then make accessible to the
>package, even if I would normally mark it private.
This begs the very interesting question about the tension between
access restriction and unit testing. C++ dodges this bullet by
allowing friends. Java has no good way to dodge it.
The problem is that marking methods private is a powerful
documentation tool. It sends a clear message to anyone reading the
code that your intent was that the function was not to be called by
any functions other than those in your class. Unfortunately the java
compiler turns this into a rule that cannot be easily thwarted.
What you'd like to do is turn off the access protection for the unit
test classes. (is there a way to do this?) But since you can't do
this you are stuck sacrificing the documentatary effect of 'private'
by using 'package' instead. Or, worse, you try to keep the 'private'
and use reflection in each of your unit test functions. Bleah.
I think the practice of using 'package' is the best of a set of bad
options. You might want to put /*private*/ in front of them as a
convention to show that they ought to be private. You might also want
to adopt a different naming convention for such functions. (e.g. put
a leading underscore in front of the method names to let everyone know
that these functions should not be called).
Robert C. Martin | "Uncle Bob" | Software Consultants
PO Box 5757 | Tel: (800) 338-6716 | your projects done.
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python|
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan