[rspec-users] Rspec api ideas, inspired by Cucumber

David Chelimsky dchelimsky at gmail.com
Fri Jul 31 07:36:45 EDT 2009

On Fri, Jul 31, 2009 at 2:11 AM, Brian Takita<brian.takita at gmail.com> wrote:
> I think I would like to stick primarily with Rspec, because I like
> working close to the code and being able to easily refactor things.
> I do like Cucumber's ability to easily define sequences of actions and
> custom plain text actions.
> Here are some api ideas I have to make those things better in rspec.
> http://gist.github.com/159123

Very cool ideas. I'm not sure whether I'd want them in rspec proper,
but I do think that rspec should let you easily plug ideas like this
into its example lifecycle management. That idea has been brewing for
a while as part of rspec-2.0, but rspec-2.0 is back-burnered until
after the book is off to print - I need to stay focused.

What you're proposing looks a lot like rbehave, which was the
precursor to Story Runner, and then Cucumber. Story Runner introduced
plain text scenarios, but still let you work in Ruby (like rbehave) if
you chose to. In rbehave, your example would look like

FIT's DoFixture does the same sort of alternating part of the method
with arguments. So you can write table rows like this:

| can have | any | number of | arguments | between text |

.. which get converted to method calls like this (pardon the camel case):


This actually dates back to smalltalk, which lets you make method
calls with something akin to keyword arguments like this:

message canHave: 'any'; numberOf: 'arguments'

It's more fluid than rbehave's name/arg structure, in which all of the
args have to be at the end, and I think its a powerful idea. The
lambda in the middle is a bit disconcerting. Maybe that bit would look
nicer in Ruby 1.9 :)

Other thoughts?


> - Brian
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list