On Wed, Oct 14, 2009 at 15:36, Joaquin Rivera P.
[email protected] wrote:
def other_complex_methods …
and the two complex methods can get really tricky to get right, I would like
to be able to write specs for them, how do you do that? I mean I cannot do:
I typically make these methods public, then test them. I use the
guideline “if it’s important enough to test, then it’s useful enough
to use somewhere else”. I usually end up using the method – or
something like it – somewhere else in my code base, then make it
public at that point, anyway.
I have also trusted, for a long time, the idea that if I want to test
it, but it’s private, then I really have a small object trying to grow
out of a larger object. I find this especially true when I have three
private methods, all related to each other, in the same class. In that
case I see the clear signal that a smaller object is getting out, so I
let that happen.
Of course, not everyone feels comfortable with so many small objects,
and not everyone feels comfortable making those methods public. If you
don’t feel comfortable to do that, then you should look for tricks in
Ruby to let you invoke that private method another way. I think
someone else suggested using send() for that. I strongly prefer
not to do that, and when I do, I generally only do it as a first step
towards refactoring the code I’m testing.
Only you can decide what to do, but if you can’t decide, then I highly
recommend making the method public, then testing it. If that makes you
dislike the design, then create a new class for the method and move it
there, making it public.
I hope this helps you.
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice :: Agile
2010: Learn. Practice. Explore.