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 :-) 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") Cheers, Josh _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
