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? 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. 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, -- Zach Dennis http://www.continuousthinking.com
On Feb 20, 2008 12:06 AM, Zach Dennis <zach.dennis at gmail.com> 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,This seems unfinished - was there more to this sentence? 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. FWIW, David> > -- > Zach Dennis > http://www.continuousthinking.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
> > 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.> This seems unfinished - was there more to this sentence? > > 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.
On Wed, Feb 20, 2008 at 11:21 PM, Kero <rspec-users at kero.tmfweb.nl> 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. 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. -- 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
On Thu, Feb 21, 2008 at 9:07 PM, Zach Dennis <zach.dennis at gmail.com> wrote:> > On Wed, Feb 20, 2008 at 11:21 PM, Kero <rspec-users at kero.tmfweb.nl> 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Thu, Feb 21, 2008 at 10:26 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> > On Thu, Feb 21, 2008 at 9:07 PM, Zach Dennis > > 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/155775And here''s another example with a bit more reuse expressed in the steps at the expense of more complexity in the steps. Which approach is better? I can''t really say one is always better than the other. I choose based on readability in a given context. Just exploring possibilities. Cheers, David
On Thu, Feb 21, 2008 at 11:40 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> On Thu, Feb 21, 2008 at 10:26 PM, David Chelimsky <dchelimsky at gmail.com> wrote: > > > > On Thu, Feb 21, 2008 at 9:07 PM, Zach Dennis > > 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 > > And here''s another example with a bit more reuse expressed in the > steps at the expense of more complexity in the steps. Which approach > is better? I can''t really say one is always better than the other. I > choose based on readability in a given context.I hadn''t even considered that using steps with the normal ruby stories was an option. This gives what I am looking for. As for symbols, they reduce a few keystrokes when you have to select them and/or see find them in a file or in the project, or copy them. They are not as readable as the strings as you point out. I may just need to buck up and/or write a macro which gives me the ability to select a string based on quotes. This is not really a story problem, more of my editor lacking a feature I want.> Just exploring possibilities.Ditto. Thanks for the reply and for the code pastes. -- Zach Dennis http://www.continuousthinking.com
On Fri, Feb 22, 2008 at 7:46 AM, Zach Dennis <zach.dennis at gmail.com> wrote:> > On Thu, Feb 21, 2008 at 11:40 PM, David Chelimsky <dchelimsky at gmail.com> wrote: > > On Thu, Feb 21, 2008 at 10:26 PM, David Chelimsky <dchelimsky at gmail.com> wrote: > > > > > > On Thu, Feb 21, 2008 at 9:07 PM, Zach Dennis > > 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 > > > > And here''s another example with a bit more reuse expressed in the > > steps at the expense of more complexity in the steps. Which approach > > is better? I can''t really say one is always better than the other. I > > choose based on readability in a given context. > > I hadn''t even considered that using steps with the normal ruby stories > was an option. This gives what I am looking for.Great! Glad to hear it. I need to get this documented.> As for symbols, they reduce a few keystrokes when you have to select > them and/or see find them in a file or in the project, or copy them. > They are not as readable as the strings as you point out. I may just > need to buck up and/or write a macro which gives me the ability to > select a string based on quotes. This is not really a story problem, > more of my editor lacking a feature I want. > > > Just exploring possibilities. > > Ditto. > > Thanks for the reply and for the code pastes.You''re welcome. Cheers, David> > -- > > > Zach Dennis > http://www.continuousthinking.com >
> > > 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 > > And here''s another example with a bit more reuse expressed in the > steps at the expense of more complexity in the steps. Which approach > is better? I can''t really say one is always better than the other. I > choose based on readability in a given context. Just exploring > possibilities.where?