As you may or may not know, I am part of the team pushing the boundaries of Agile & XP at Industrial Logic with Josh Kerievsky. As such, I'll be posting some of my rantings in our new Industrial Blogic album (the blog portion of our truly kick-ass "Greatist Hits" eLearning platform).
My debut there is a classic, but so grossly unknown topic. Summarize it as so: if you want to test your private methods, take out a ruler and slap yourself over the wrist. As a personal mentor of mine, J.B. Rainsberger, used to tell me: "if you really need to test that private method, then it should go somewhere else dude."
Check out the rest of the story here, and while you're in add our Industrial Blogic to your RSS reader, we'll be keeping it hot there.
Posts
Q "when microtesting, doing TDD, is it okay to test a private method?"
ReplyDeleteA "how did you manage to end up with a private method?"
When I do TDD I don't write many private methods. Why would I? Since I don't write a method from scratch other than to make a failing test pass (that's the "test driven" part of TDD) then such a method pretty much has to be public. Why would I then make it private (and break the test)?
One possibility is that I did an Extract Method (from a method already tested). Some folks use "private" as a marker to mean "this method tested indirectly". I'm not 100% comfortable with that. I think that's really a work-around for weak coverage tools.
If we did do that Extract Method we are well on the way to the discovery of a new class in the style that you suggest. But the first thing to ask, I think, is: if you are doing TDD, how did you manage to end up with a private method.
"purity" vs "in practice"? "purest" vs "in reality"? These are false dichotomies.
ReplyDeleteThe technique is what it is. You can do it, or not do it. It looks to me as if you're coming from a place where you don't practice TDD as if you meant it. A place where you don't believe that TDD could "really" work "in practice". Seems like an opportunity missed.
Keith
Hi Keith,
ReplyDeleteHm. I don't think we're quite on the same page.
2 things:
First, the original scenario described in the blog is in fact painted from the POV of someone who may not fully get the full essence of TDD - that's the point of the blog: "hey, if you're experiencing this, then heed this message about how you might better understand/apply TDD".
That said though...I'm still pretty sure that even as an experienced/disciplined TDD practitioner, one is certain to get themselves into this position. The position is this: I test drove an object to life. I come back with fresh eyes and look at this object (and its tests) and decide that it's doing too much, and its tests aren't so great afterall. I decide to extract and object and write focused tests for the behavior of this new object.
This is evolutionary design. We change our mind, yes?
Bottom line with the "purity vs in practice" -> book says my tests will drive me to the right design from the start, whereas reality is that I'll often still get it wrong the first try. And that's okay.
Are we kosher?
Blogger ate the previous version of this comment.
ReplyDeleteI don't believe in "right" and "wrong" in design, only better and worse misfit between current solution and current problem. Having a partial solution changes the problem, and that changes the direction in which the design needs to go next to reduce the misfit. The feedback (with safety) that comes from tests in TDD helps to find that direction and move quickly in it.
My point is that for this to work we have to really do TDD, not tell ourselves some story about the alleged practicalities of the so-called real world and then go about the thing in a half-hearted way.
It is exactly the experienced/disciplined TDD practitioner who finds themselves needing to change existing classes and tests: they have to be experienced enough to notice the opportunity for improvement and disciplined enough to do something about it. This is a necessary part of doing TDD, as far as I know.
All sounds good to me.
ReplyDeleteSo then, I'm not clear anymore where/how/if we are disagreeing?