On 10/16/07, Josh Chisholm <[EMAIL PROTECTED]> 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. Cheers, David _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
