rspec users - Jul 2008 - Re-use scenarios from another story file?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080703/7e96b1ca/attachment.html>

On Jul 3, 2008, at 11:57 AM, David Salgado 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
> 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
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

> 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?
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080704/de970c3e/attachment.html>

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 Salgado <david at digitalronin.com>
wrote:
>
> 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?
>>
>
> 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
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080704/fb4ce452/attachment.html>

Zach Dennis wrote:
> 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
>
+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

Many thanks for the advice, guys.

David

2008/7/5 Ben Mabey <ben at benmabey.com>:
> Zach Dennis wrote:
>
>> 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
>>
>>
> +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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080705/705f085e/attachment-0001.html>