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,
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.
just another approach. Plain text is great for some situations, but so
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,
Why would this be specific to scenarios written in Ruby?
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.
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:
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.
just another approach. Plain text is great for some situations, but so
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,
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.
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.
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.
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?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Depends on the team, really, and how involved