[rspec-users] spec-ing private methods?
zach.dennis at gmail.com
Thu Oct 15 22:42:20 EDT 2009
On Wed, Oct 14, 2009 at 5:22 PM, Joaquin Rivera Padron
<joahking at gmail.com> wrote:
> 2009/10/14 Ashley Moran <ashley.moran at patchspace.co.uk>
>> On 14 Oct 2009, at 20:49, Scott Taylor wrote:
>>> On Oct 14, 2009, at 3:36 PM, Joaquin Rivera Padron wrote:
>>>> def complex_method...
>>>> 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
>>> You have a few options:
>>> 1. Make the method public in the object you are testing
>>> 2. Make the method public in the test case
>>> 3. Don't test the method
>>> 4. Use __send__ or (send) to call it.
>>> 5. Refactor private methods to a new object, and make the methods public
>>> in that object.
>>> Most of those options suck (esp. 1, 2, 3, & 4) - usually it represents a
>>> design flaw (you are doing too much in your class).
>> I'm with Scott, this usually indicates a design flaw, and 5 is usually the
>> solution. The clue is in the names you gave them - you shouldn't have
>> complex methods, especially private ones.
>> Can you post any of the code so we can see where the complexity/problem
> hey ashley,
> the code itself is not very interesting, it's some fast hacking I'm doing
> dumping chess positions into a string, and then the methods given the
> character index on that string should translate it to two-dimensional
> vectors in the board, boring: mainly math calculations multiplying columns
> by some number and adding row numbers and such, and during the spec-ing of
> the public method the question arose...
I might shift my focus from whether or not these methods should be
made public or moved to another class and first make sure I had
written examples that focused on the behaviour I was interested in. I
have found that having those tend to be a good help when thinking
about making private methods public. Even if you find you don't need
these methods to be public you will find the examples afford you a
great deal of freedom to refactor that code in a number of ways or by
simply leaving them as private methods all while leaving the examples
> and yeah, I think 5 it my favorite at the moment,
> they don't have to be
> private anyway, also IMHO testing private methods through the public API
> it's not in general applicable (only thinking here, no code sample)...
> but anyway I wanted to hear what you guys think about it
Behaviour first. That will help you identify if you're dealing with
different responsibilities which might push you to extract a new
object, or if you're dealing with logic that goes together (in which
you might keep well-named private methods), or if you want to pull out
some of the dry and boring math calculations out into a method on some
If you put good examples in place you'll be able to change your mind
later without having to maintain *brittle* specs while having a great
deal of freedom for re-organizing the implementation in a number of
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
More information about the rspec-users