JUnit test organiaztion?

JUnit test organiaztion?

Post by William Pietr » Wed, 01 Aug 2001 06:29:03



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.

I don't like this entirely, but I haven't found a better choice. How do
other folks handle this?

William

 
 
 

JUnit test organiaztion?

Post by Jason Che-han Yi » Wed, 01 Aug 2001 11:18:50



Quote:

> 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.

I've tended to start doing same package as well although I put the tests in
a separate directory.  Wanting to test private methods is a design smell and
I'd prefer to extract another class... but I find that sometimes, I'm not
sure how to do that yet and I'd rather switch to package and get the test
coverage now.  I've only noticed this occuring when I'm doing test after vs
test first.

 
 
 

JUnit test organiaztion?

Post by zack » Wed, 01 Aug 2001 17:28:36


Try to do something like this:

public void testMyPrivateMethod {
  MyClass myClass = new MyClass();
  try {
      Class c = MyClass.class;
      Method method = c.getDeclaredMethod("myPrivateMethod", null);
      method.setAccessible(true);
      method.invoke(myClass , null);
    } catch(Exception e) {
      fail(e.toString());
    }

Quote:}

/zacke


Quote:

> 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.

> I don't like this entirely, but I haven't found a better choice. How do
> other folks handle this?

> William

 
 
 

JUnit test organiaztion?

Post by Robert C. Mart » Fri, 03 Aug 2001 22:36:18


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

 
 
 

JUnit test organiaztion?

Post by Ilja Preu » Fri, 03 Aug 2001 23:49:57


Quote:> What you'd like to do is turn off the access protection for the unit
> test classes.  (is there a way to do this?)

I did handle this with the help of inner classes:

public class Foo {
  private Bar bar; // no public getter/setter

  public class TestInterface {
    public Bar getBar() {
      return bar;
    }
  }

Quote:}

This makes the public test interface explicit. And it's possible to remove
the test interface from production code without touching the source code.
Granted, the test gets a little bit ugly:

testBar = testFoo.new TestInterface().getBar();

As I think of it as a code smell anyhow, the ugliness doesn't bother me at
all.

ciao, Ilja

 
 
 

JUnit test organiaztion?

Post by Keith Ra » Sat, 04 Aug 2001 01:53:36




> 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).  

Instead of an underscore, how about "private"  e.g.,
   void privateComputeX(){...}
 
 
 

JUnit test organiaztion?

Post by Micah Mart » Sat, 04 Aug 2001 05:45:25


This is a problem that I have thought about for some time.  I'd like
to know what objections people have to the following practice.  This
is assuming you work in an XP environment.

        If the function you'd like to test is private, make it public.
        Even better,  make untested private functions public and write
a test for them.

It seems to be the simplest solution.  What do you think?  Am I crazy?

Micah



>Try to do something like this:

>public void testMyPrivateMethod {
>  MyClass myClass = new MyClass();
>  try {
>      Class c = MyClass.class;
>      Method method = c.getDeclaredMethod("myPrivateMethod", null);
>      method.setAccessible(true);
>      method.invoke(myClass , null);
>    } catch(Exception e) {
>      fail(e.toString());
>    }
>}

>/zacke



>> 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.

>> I don't like this entirely, but I haven't found a better choice. How do
>> other folks handle this?

>> William

 
 
 

JUnit test organiaztion?

Post by Jason Che-han Yi » Tue, 07 Aug 2001 02:32:45



Quote:> This is a problem that I have thought about for some time.  I'd like
> to know what objections people have to the following practice.  This
> is assuming you work in an XP environment.

> If the function you'd like to test is private, make it public.
> Even better,  make untested private functions public and write
> a test for them.

> It seems to be the simplest solution.  What do you think?  Am I crazy?

> Micah

The documentation aspect of setting something as private still makes me wary
of just switching it to public.  I'm slightly less wary of switching to
package so I do that.

As for whether you're crazy... :)

 
 
 

JUnit test organiaztion?

Post by Kimball Samps » Thu, 09 Aug 2001 22:00:25


I really don't like the Unit Tests in the same package.  I do the
parallel package with same name post fixed with "test".  myPackage,
myPackageTest.

I use "protected" quite a bit instead of private.  My opinion is, if
it really is that private, then it doesn't need to be specifically
unit tested, instead,  I assure it's getting tested by calling one of
the higher level methods that call the private methods. All a matter
of style and opinion.  I just double up on testing the
protected/public methods to make sure the private ones are working.
In the real world, that's how these things are going to work
regardless.

So, my problem is, calling "protected" not "packaged" methods from a
class not inheriting the test subject class.  Generally, my unit tests
require writing two classes.  The Test suite class, and a wrapper
class that inherits the class being tested.  Basically, all the
protected methods I need to call are overridden as public in the
wrapper class.  I.E.

class MyClassWrapper {
   public void someProtectedMethod(...){
      super.someProtectedMethod(...);
   }
   ...
   ...

Quote:}

Works for me very well, and my production code is totally separated
from my AUT code.

Regards