Hi All
Is there a way to have “pre-requisite” story scenarios, and include them
using GivenScenario in a different story file?
i.e. I’d like to have a file “prereqs.story”, with “Scenario: A common
setup”, and then in “somestuff.story” have “GivenScenario: A common
setup…”, and have the scenario go on from there.
I know I can extract logic into steps, but I’d like the pre-requisite
scenarios to have some assertions, and it doesn’t feel right to put
assertions in steps (if that’s possible).
I’ve had a dig through the rdoc and the source, and I couldn’t figure
out
whether it could be done, or how to do it. Is this kind of thing
possible
and/or sensible?
Many thanks
David
On Jul 3, 2008, at 11:57 AM, David S. wrote:
Hi All
Is there a way to have “pre-requisite” story scenarios, and include
them using GivenScenario in a different story file?
i.e. I’d like to have a file “prereqs.story”, with “Scenario: A
common setup”, and then in “somestuff.story” have “GivenScenario: A
common setup…”, and have the scenario go on from there.
Unless you’re looking for the steps to show up when you run things,
why not just have a helper method that does the setup for you and then
have a Given step that invokes that method?
I know I can extract logic into steps, but I’d like the pre-
requisite scenarios to have some assertions, and it doesn’t feel
right to put assertions in steps (if that’s possible).
I’m not sure understand this. Don’t you have expectations (assertions)
in all your Then steps?
David
all your Then steps?
Sure. I was just hoping I could keep my prereq stuff as a story in its
own
right - more for clarity when discussing requirements than for any other
reason. If it’s just a step or a helper method, then that particular
story
is reduced to a one-liner. I know I could always do both, and not be
100%
DRY, so I guess that’s what I’ll do.
Thanks for the advice
David
Zach D. wrote:
features and in the maintenance of ongoing development or changes to
Sometimes I would end up having to reorganize, or split one step into
the same, I pull that out into a helper much like David suggested. Now
Zach
+1. I have had the exact same experience. Reusing story steps too
aggressively tends to lead to awkward stories that have a higher
maintenance cost for several reasons.
-Ben
A short experience report regarding this thread:
Early on when stories were introduced to rspec’s code base I started
using
them, and I tried some different techniques to see what the sweet spot
was
for using stories in actual development. To do some of this I made
modifications to rspec (this was before stories were released
officially)
In my experience I found that trying to build up a highly re-usable set
of
steps caused a lot more overhead, both in the creation of new features
and
in the maintenance of ongoing development or changes to existing
features.
In practice has been much easier for me to build reusability in the form
of
helper methods which sit behind steps, and even to allow yourself to
have
very simple (even one line) step definitions.
One problem I noticed I ran into was that I spent too much time trying
to
organize and group reusable sets of steps. This made it difficult when
one
story changed in how it did something, but another one did not, and it
made
my stories rely on several step files (ie: steps_for =>
[:site_navigation,
:project_navigation, :project_creation, etc.]). Sometimes I would end up
having to reorganize, or split one step into two, and then go find all
places where things would be affected by this, etc.
I also found that by focusing on this kind of step reusability I was
writing
much more granular stories (ie: implicit story style). When trying out
what
is now known as the declarative story style I have found that
introducing
new features and changing existing features takes much less time when
all of
my steps for a story are in as few as possible step files (typically
just
one step file). When I notice that two stories both have a scenario
where
the implementation of a step is the same, I pull that out into a helper
much
like David suggested. Now if one of those stories changes, you can
change
its step w/o affecting any others.
In summary, don’t focus on step reusability across stories, instead pull
out
helpers while allowing the steps to be defined separately for their
respecive stories. This will make it easier to introduce new features
and
maintain/change existing features over the lifetime of the app.
HTH,
Zach
On Fri, Jul 4, 2008 at 4:17 AM, David S. [email protected]
Many thanks for the advice, guys.
David
2008/7/5 Ben M. [email protected]: