Testing Private Methods

Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")

Moderator: General Moderators

Post Reply
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Testing Private Methods

Post by Ambush Commander »

I did a quick google search and noticed that there's a long standing debate on this. I have several questions:

* What are your views on testing private methods and,
* How would you test methods explicitly declared private in PHP5?
* Maybe you should be a bit more discerning before making things private?
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Personally, I wouldn't test private (or protected), methods. Thats an implementation detail. Which I don't think should be enforced via testing. You want to test that the class's public interface meets its spec. So, the private methods should be tested indirectly via testing the public method's interface.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

I haven't heard the argument for but it sounds like a very bad idea.

When you refactor, the interface might remain constant while the internals are shuffled around. Testing private methods would interfere with that (ie the test case would have to be edited to keep pace rather than acting as a constant touch stone to guide the refactoring).

I think testing should focus on interfaces. That helps to improve design - encapsulation is what OOP is all about. Testing private methods has got to be evil.

I'm trying to think why anyone would want to. A programmer might have missed the smell of a new responsibility and a need to spawn another class. If methods are rather bloated or there are lots of them you might find it harder to get a fine enough grain against the interface alone. Testing private methods could maybe help to debug something which isn't obvious otherwise. I don't know really. I expect they'll pay for their sins though.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Thank's for your replies. Here's the google search I did: http://www.google.com/search?q=unit%20t ... e%20method and for some strange reason the first two results are anti-private method testing and the second two results are pro-private method testing. I think I'll go no private method testing. :)
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

I had a quick look at one of the links which recommends testing private methods.

The example he gives mentions a sorting algorithm going awry but the failing interface assertions aren't giving enough fine detail to find the problem quickly. That's exactly what I was getting at above: if the algorithm is complex enough for this to be an issue, it probably should be refactored into a new object, with its own fine-grained tests.

Testing smells can be a sign that the design needs a rethink.
Post Reply