Hello Joaquin, On Wed, Oct 14, 2009 at 5:22 PM, Joaquin Rivera Padron <joahk...@gmail.com> wrote: > hello > > 2009/10/14 Ashley Moran <ashley.mo...@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: >>> >>>> private >>>> 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 >>>> do: >>>> >>>> object.some_private_method >>> >>> 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 >> is? > > 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 intact. > > 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 utility class. 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 imaginable ways. -- Zach Dennis http://www.continuousthinking.com (personal) http://www.mutuallyhuman.com (hire me) http://ideafoundry.info/behavior-driven-development (first rate BDD training) @zachdennis (twitter) _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
