[rspec-users] Step matchers

David Chelimsky dchelimsky at gmail.com
Tue Oct 16 08:58:00 EDT 2007

On 10/16/07, Josh Chisholm <joshuachisholm at gmail.com> wrote:
> Hi all. I'm with David in that plain-text specs are my holy grail. I
> have actually been experimenting with this idea since I first saw the
> story runner. My interpreter (spike!) would execute "specs" against
> "proofs", but I tried to put a bit more into the grammar.
> Specifically, the interpreter would manage the flow of the spec (I
> used the terms create/expect/act/verify) by setting up and reusing the
> "class variables" between steps. For example:
> "given a dog" interprets as
> 1. instantiate a Dog and assign it to class variables @he, @she, @it
> "given a dog with a bone: Fido" interprets as
> 1. instantiate a Dog and assign it to class variable @fido
> 2. find a matcher for ":dog with a bone" and call it with @fido
> "when Fido barks at Felix" interprets as
> 1. find a matcher for ":dog barks at :victim" and call it with @fido, @felix
> I found that two modes of "define_then" statements were needed: one
> called before its whens (interaction testing) and one called after its
> whens (state testing).
> Is that going too far? Yes my parser and interpreter were more than 60 lines :-)

This does seem more complex than what we're thinking of doing. Are you
using this on projects? Would you mind posting a couple of specs so we
can see what they actually look like?

> What I can say is that coding "libraries" of "step matchers" takes
> little away from the maintainability (or programmer happiness!) For
> example, the runner can warn things like:
> not yet implemented: act ":dog with a bone" (to support "given a dog
> with a bone: Fido")

We'll definitely do something like that, though the messaging won't be
as granular (saying which part of a step is missing).

Cool ideas.


More information about the rspec-users mailing list