No private methods

RE: No private methods

Klaus Probst [MVP] — Sat, 12 Jun 2004 01:17:00 GMT

But the question is bogus to begin with. Private methods should exist only in support of exposed entry points and public aspects or facets in your components. There should be *absolutely* no requirement that involves even remotely trying to get to them. A good testing strategy should cover them completely, since they'll be excercised as the public interface is put through its paces.

re: No private methods

Karl — Sat, 12 Jun 2004 02:54:00 GMT

aside from the debate about whether private methods should be tested, any thoughts on this solution for testing them:

#if UNIT_TEST
public static ArrayList GetCategories_UnitTest (string filename){
return GetCategories(filename);
}
#endif
private static ArrayList GetCategories (string filename){
//implementation
}

re: No private methods

Jonathan Cogley — Sat, 12 Jun 2004 03:04:00 GMT

I get asked this question frequently when presenting on TDD - in fact I even have a slide on it! I tend to agree with what Klaus said. Don't think about testing every method, rather focus on testing features. Remember that TDD comes from XP where business value is key ... therefore each test should be focusing on an aspect of business value and all code supporting it will then have full coverage.

Your "Extract Class" idea is interesting but your design should be dictated by refactoring after getting to green rather than to test each method. Think "tests == features"!

re: No private methods

Adi Robinson — Sat, 12 Jun 2004 09:44:00 GMT

I your idea because it's so controversial, from an O-O perspective. On the extract class refactoring I have to say that object domain pollution and loss of cohesiveness in the abtractions being modeled are good reasons to refute it...however command pattern and the strategy pattern represent approaches where externalising a feature can have some design benefits.

However, from a TDD perspective I think we have to decide on one of two approaches.

1) Do I only test my public interface - and thereby if my public interfaces honours it's contract the discrete private implementations MUST work (at least within the bounds of the values passed to them from the public interface, AND assuming exhaustive public interface testing)

or

2) Do we test private methods because as stand alone functional units they have pre and post invariants I want to force to be correct?

You could argue, that if you've done proper TDD, then your private methods emerged as extract method refactorings once duplication occurred and so hence where tested as part of that design evolution? And, given that you would clearly re-run your old tests on the now multi-method-provided implementation of a once contiguous code block means that if you get the green light you are indeed testing your private methods.

I'm not entirely sure either way.

re: No private methods

Nicole Calinoiu — Sat, 12 Jun 2004 15:04:00 GMT

There's another potential consequence that you didn't mention: impact on the performance/security trade-off.

Ignoring for the moment the potential impact of reflection into low accessibility members, a private method sits inside the input boundary of its class. For most private methods, very little parameter validation is necessary since this has already been performed elsewhere in the class or the values were safely generated inside the same class. However, if the method becomes a public method of another class, all parameters must be re-validated completely since their values are supplied from outside the input boundary of the new class. In general, a performance decline should be expected, particularly if one is calling the method from within a loop.

Obviously, it is possible for callers outside a given class to be considered trustworthy, so the above is a bit of an over-simplification. However, the general problem applies any time you open a low accessibility member to more callers.

That said, if reflection into low accessibility members is a concern, the method is probably already written as if it were public, so the performance impact of the change isn't likely to be a consideration.

re: No private methods

Michael Swanson — Sat, 12 Jun 2004 15:59:00 GMT

And it's "jibe", not "jive". :)

The most extreme thing that could possibly work

jaybaz [MS] WebLog — Mon, 14 Jun 2004 07:39:00 GMT

re: No private methods

Mikhail Arkhipov (MSFT) — Mon, 14 Jun 2004 06:14:00 GMT

Programming reflects real life. 'No private methods' is like 'no private life' :-) If someone is calling you and asking for something you have right to talk to your significant other before answering. I believe every object has right to the private life as well :-).

Seariusly, exposing everything increases test matrix. If before a private method A was only supposed to be called from B now anyone can call A at any time.

re: No private methods

jaybaz [MS] — Mon, 14 Jun 2004 18:21:00 GMT

Michael: You're right! A goggle search on "define: jive" didn't mention compatibility. A search on "define: jibe" was mostly about sailing (yay) but also had this entry at the very bottom.

"be compatible, similar or consistent; coincide in their characteristics"

http://www.cogsci.princeton.edu/cgi-bin/webwn?stage=1&word=jibe

re: No private methods

Darren Oakey — Tue, 15 Jun 2004 01:50:00 GMT

I know you are just throwing up a question, what about "no private methods" - but I'd like to squash it :)

I always make an attempt to make as much of my underlying implementation as private as is theoretically possible, and think that's a good thing..

I think almost all the advances in modern languages and concepts come down to information hiding - or, to look at it another way - "simplifying".

In the bad old days, I had to understand every bit of making an ftp connection, listening on a port, worrying about synchronisation, etc etc etc.

Now I just go "new FtpConnection( server)", and myConnection.GetFile(). Over time, with many people using the same library, in the same way, we find the bugs - it gets more and more robust - deals with more and more situations, and the code gradually improves.

This occurs because we have a tiny interface as wrapper to a large amount of functionality. Even though it may sometimes be restrictive, people always use it the same way, because that's the only choice they have.

And that's how software improves. Expose all the underlying interface, allow people to change things, and we've just stepped back 20 years into unproductiveness...

Anyone who has programmed for a long time knows that Limitations = productivity. (Which is why, as someone who's experienced in everything from asm to vba, I'm more likely to write a quick program as a perl script than a beautiful c++ structure - because it'll take me 1/10th the time, and be 100% stable)

re: No private methods

Travis — Tue, 15 Jun 2004 03:30:00 GMT

One positive side effect might be amazing code reusability.

Trackback

Travis — Tue, 15 Jun 2004 03:48:00 GMT

Trackback http://travis.pettijohn.com/blog/comments.php?entry=98

re: No private methods

jaybaz [MS] — Tue, 15 Jun 2004 04:05:00 GMT

Travis: I hope so. Let's try it & see.

re: No private methods

jaybaz [MS] — Tue, 15 Jun 2004 04:08:00 GMT

Darrel: I think your concern sounds valid. But I hope that the external interface doesn't charge, so things work out ok

re: Testing Private Methods/Member Variables - Should you or shouldn't you

James Newkirk's Blog — Thu, 17 Jun 2004 03:59:00 GMT

re: Testing Private Methods/Member Variables - Should you or shouldn't you

James Newkirk's Blog — Thu, 17 Jun 2004 04:05:00 GMT

re: No private methods

Iain — Thu, 17 Jun 2004 15:08:00 GMT

I think it's kind of self-evident that the private methods should be tested, because unit testing seems to me to be about testing the smallest testable pieces, as opposed to testing generally, which seems to be about testing all the big pieces.

This makes it a question of mechanics. The really obvious solution is to have a compiler option that makes the compiler spit out reflection-based invocation code for private functions, so you just write your tests for private members like you do for everything else and pass the violate-encapsulation switch to the compiler, or somehow indicate it otherwise.

I might have to try implementing this with the mono c# compiler.

It would be possible to just write the reflection invocations for private members yourself, but I think that's just going to make the tests harder to read by a large enough margin that it's going to be a pain.

The violate-encapsulation would be subject to abuse, but I can't see it being any worse then the ability to reflect on and therefore invoke private methods when in full trust already is.

Jay Bazuzi

public MattBerther : ISerializable — Wed, 23 Jun 2004 21:42:00 GMT

One of my favorite bloggers as of late is Jay Bazuzi (rss), who works on the Visual C# IDE team at Microsoft. Give him a read; he's got some posts that are sure to melt your brain, such as "no...

Refactoring the C# Express Starter Kit

jaybaz [MS] WebLog — Fri, 20 Aug 2004 01:17:00 GMT

is private method an antipattern « monkey island

is private method an antipattern « monkey island — Sat, 05 Jan 2008 22:30:52 GMT

PingBack from http://szczepiq.wordpress.com/2008/01/05/private-method-antipattern/

jaybaz MS WebLog No private methods | Cellulite Creams

jaybaz MS WebLog No private methods | Cellulite Creams — Wed, 10 Jun 2009 04:26:20 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=9021

jaybaz MS WebLog No private methods | Quick Diets

jaybaz MS WebLog No private methods | Quick Diets — Sat, 13 Jun 2009 16:53:07 GMT

PingBack from http://quickdietsite.info/story.php?id=1309