[rspec-users] RSpec Requestable Examples

Zach Dennis zach.dennis at gmail.com
Mon Jan 30 23:46:03 EST 2012

On Sun, Jan 29, 2012 at 3:04 PM, Lenny Marks <lenny at 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

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).


More information about the rspec-users mailing list