On Sun, Jan 29, 2012 at 3:04 PM, Lenny Marks <le...@aps.org> wrote: > > On Jan 27, 2012, at 9:56 PM, Zach Dennis wrote: > >> I would be interested to hear any thoughts from the community about >> the ability to request specific examples from a shared example group >> as expressed in the rspec-requestable-examples gem. >> >> Here's the post that introduces them: >> http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples >> >> Git repository: https://github.com/mhs/rspec-requestable-examples > > I've successfully used macros to get similar results, like in the gist below: > > # macros approach to requestable examples > https://gist.github.com/1700352 > > Curious if you see any big advantages over the macros approach. >
Both approaches can get the job done technically speaking. Here were some goals of rspec-requestable-examples: 1. allowing individual examples to be selected from a shared set of examples 2. when a user selects a non-existent example communicate that to them so they can implement the example or fix their typo 3. be consistent and complementary with RSpec's forms 4. be consistent with RSpec method of delivery (communication) With these goals macros let's you technically do #1 and #2: * modules allow you to create shared sets of methods which can be shared * when referring to a non-existent method Ruby will yell at you But it fails for #3 and #4: * RSpec has a shared example group form already. Modules are not needed at this level because RSpec provides a higher level concept which provides the utility of sharing examples (it just didn't have baked in the ability to select individual examples). Plain old Ruby modules breaks away from this form and does not complement what RSpec is doing. * RSpec communicates to the user in terms of nice spec output for passing, failing, and pending examples. It is less work for a user to stub out an example which is not yet implemented as they write their spec and to move on, then to have to see low-level Ruby undefined method errors and have to go stub it out right then and there. I would rather have an unknown example be pending so the user could take care of it at the time they were ready. And even though using "extend ..." and ruby methods are easy to do (and they do technically work) I find it complicates my specs because they exist at a different level of language and communication than all of the other components in my specs. I prefer the language and forms I use to be as consistent as I can make them in my specs. For me, this helps my rhythm of creating software. There is a level of consistency and continuity I want my code to have and in the rspec-requestable-examples approach I try to find that with what RSpec already provides and how it is already being used. I feel like the macro approach attempts to shoehorn in a solution and that's what I've done that in the past, but I think the requestable/selectable examples is better now for reasons above mentioned. In the original blog post it may have sounded like we hit problem A and then in 5 minutes we came up with a solution. When really that's not the case. I've done the macro approach a number of times in the past and never felt comfortable with it, but it worked and we didn't have a better way. But this time, we finally found a way to make do it a little better (at least in our opinion). -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
