• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

The "JUnit and privates" debate

 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
J.B., where do you stand on the eternal debate about testing private methods? On one end of the spectrum are the "only test the public interface" folks, and on the other end are the "test everything, even if it means opening up methods that might otherwise be private" folks (and the "nothing should be private" folks, too.) Or there are those ugly reflection tricks, of course; surely you wouldn't advocate using those...
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I won't answer for J.B., but hopefully you mind if I chime in...

From Sun's documentation: , "A private member is accessible only to the class in which it is defined." Therefore, anything else is public, in some sense of the word.

The public interfaces must somehow act upon the private members, otherwise you wouldn't have them. There must be some noticeable affect on the system when a private member is changed, test that.

If you have no way of measuring/testing the effect on the system when a private member is changed you have a design flaw. If you are able, you should update the design accordingly, if not I guess you have to fall back on reflection or some other work around. My preference has always been to heed my tests by updating the design.
 
author
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JUnit Recipes includes some advice on testing private methods using JUnitX, but you'll notice the recipe title is "Test a private method if you must".

To me, there's no great debate. I prefer not to test private methods, because that requires real work. If I must test a private method, because I cannot change the code under test, but I nevertheless am worried it might fail, then I go ahead and test it. For me, there are two main ways I get private methods:

* Eclipse's "Extract Method" refactoring
* Legacy code

I have no problem making non-public methods public to test them. I have yet to see a compelling situation in which I would hesitate to do so, but sometimes you can't, and when you can't, use JUnitX.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How come the only choices are public vs private? What happened to making the methods/fields package-private so the tests can access them, but they are not really public.
 
J. B. Rainsberger
author
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jeanne:

I never use the package-level or protected access modifiers. I just find that I never need those levels of protection. To me, part of a class is either open or closed. Various degrees of "open" serve only to complicate my life, and my life is complicated enough.
 
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe I don't hardly ever do this so that's why I'm confused but the JUnit FAQ gives instructions on how to do this using a PrivlegedAccessor class.

Is there a 'best practices' way to test private methods that involves using the Eclipse thing you mentioned or JUnitX?

Thanks for the insight on a method is either Open or Closed and everything else complicates matters. That was interesting. I guess it's like being sort of pregnant - you are or you aren't.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wouldn't use package-private access for any purpose other than testing (although some of my coworkers disagree.) I find that it creates more readable tests than using reflection/junix to access privates.

JB, Is not using package-private access for tests a best-practice or a personal preference?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
JB, Is not using package-private access for tests a best-practice or a personal preference?

I'd say personal preference, based on earlier discussions in several forums.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Lasse!
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The best argument so far for not using package-private access has been "the method signatures look stupid in my IDE if there's no access modifier"
 
J. B. Rainsberger
author
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't believe in best practices. It is definitely personal preference, but I also think it's a pretty good practice.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

It is definitely personal preference, but I also think it's a pretty good practice.


Ok. Thanks. I disagree, but I guess that what makes it a preference

I created a thread in OO (as it isn't really about testing) because I am curious what others think on this topic.
[ August 12, 2004: Message edited by: Jeanne Boyarsky ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
The best argument so far for not using package-private access has been "the method signatures look stupid in my IDE if there's no access modifier"



Oh, yeah, it really does! :roll:
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
J. B. Rainsberger:

I never use the package-level or protected access modifiers.

Are there no recipes in the book for testing protected methods? I find I really need such methods for code reuse within inheritance hierarchies.
 
J. B. Rainsberger
author
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, there's no recipe for testing protected methods, although I probably do mention that placing test code in the same package as the production code allows access to protected/package access methods.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic