On Thu, Feb 21, 2008 at 9:07 PM, Zach Dennis <[EMAIL PROTECTED]> wrote: > > On Wed, Feb 20, 2008 at 11:21 PM, Kero <[EMAIL PROTECTED]> wrote: > > > > I was working on a past project tonight to trunk which is using the > > > > old story format. IE: > > > > Given "desc" do / end > > > > When "someting "do /end > > > > etc.. > > > > > > > > Is this officially supported, or is this just something that hasn't > > > > been ripped out yet? > > > > > > It's funny to me that this is "Old Style" in your view. It's really > > > just another approach. Plain text is great for some situations, but so > > > is writing in Ruby :) Depends on the team, really, and how involved > > > the customer is in actually doing the typing. > > > > > > > If it is officially supported how attached are people to the re-using > > > > of do/end blocks which match the same description. Every now and then > > > > it bites me and I end up having to change one of the descriptions to > > > > differ textually then another. > > > > > > Why would this be specific to scenarios written in Ruby? > > > > > > > IMO it is kind of annoying. A story > > > > part description may have the same description as another in the same > > > > scenario. Sometimes the sequence of steps provide the context, > > > > If I understand you correctly, then we had a discussion on this: > > > http://rspec.lighthouseapp.com/projects/5645/tickets/167-blocks-provided-to-when-then-clauses-should-always-be-used > > and concluded that same-description means exactly-same-step, then > continued > > > http://rspec.lighthouseapp.com/projects/5645/tickets/172-warn-or-fail-on-re-specified-when-then-clause > > which is still open. > > > > Thanks for the links Kero. That ticket is the issue that I am talking about. > > > > > > > This seems unfinished - was there more to this sentence? > > There may have been, but I cannot recall at this point. > > > > > > > > I think this is just a matter of documentation. If we got rid of > > > block-sharing we'd be promoting much more verbose scenarios with a lot > > > of redundancy. I think it's here to stay. > > > > An implementation of Kero's second ticket [0] would definitely help. > That extra feedback of "Hey, you already implemented this story part! > Right there on line 11" would be great.
Agreed. If someone commits a patch with specs, I'll be glad to apply it. Dan has already stated (I think in that ticket) that a message like you suggest would be appropriate, and I agree. > A smaller annoyance associated with this is that story parts without > blocks can get lost visually when in a sea of story parts with do/end > blocks. I may be biased because on the last few customer driven > production projects I've been using test/unit story runner, which I > think is simpler and more developer friendly. [1] > > As you mentioned David, "Plain text is great for some situations, but > so is writing in Ruby". This begs the question now that we have plain > text stories. Can we make the ruby-based stories more developer > friendly? Perhaps remove string identifiers, use symbols. Quit passing > in blocks to story parts, assume each story part is a method call, and > I'm sure there are other things that could be suggested as well. You can do all of this already except using symbols instead of Strings, something which doesn't strike me as more readable. Here's an example: http://pastie.caboo.se/155775 With this approach, the step definitions are decoupled from the steps in scenarios, which function just like method calls only better, because they can include $tokens that get converted to block arguments, supporting re-use of the step definitions. The steps_for block can be in the same file or not, you can have multiple stories in one file, you can associate multiple step groups (the result of steps_for) with the same story. You can define steps with the same identification strings in different groups that operate at different levels (for example you could have two implementations of "When I submit the event creation form", one which works using webrat or similar, and another which uses selenium), allowing you to use the same scenarios to drive both in-memory and in-browser steps. FWIW, David > > -- > > Zach Dennis > http://www.continuousthinking.com > > 0 - > http://rspec.lighthouseapp.com/projects/5645/tickets/172-warn-or-fail-on-re-specified-when-then-clause > 1 - http://www.continuousthinking.com/2007/11/14/test-unit-story-runner > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
