Matt,
I am open to referring to separate documentation/scenario. It would be nice if I can optionally make it appear in the tests but that is a nice to have. Is this just an example/idea or is it possible to do this currently? Thanks, Wes From: rspec-users-boun...@rubyforge.org [mailto:rspec-users-boun...@rubyforge.org] On Behalf Of Matthew Krom Sent: Thursday, April 09, 2009 2:44 PM To: rspec-users Subject: Re: [rspec-users] Reuse of Cucumber Features Two other brainstorms: Brainstorm 1: Given an empty flights database And aircraft XX1 flight number XX0001 departs on 03Mar2009 at 1000 And aircraft XX1 flight number XX0002 departs on 03Mar2009 at 1400 And aircraft XX1 flight number XX0003 departs on 03Mar2009 at 2100 Brainstorm 2: # Sets up all the flights in your scenario Given flight database scenario A In #2, you have to reference separate documentation on what is contained within scenario A. This may or may not be acceptable to your process, but it can work quite well if you are comfortable referring to the separate documentation to keep things straight. Matt Krom I know this is an older post but I have a similar but different set of scenarios I need to handle. I have a set of flight related scheduling features, such as delay, reschedule, and cancel, each with multiple scenarios that have an effect on later flights in the schedule (there are a lot of scenarios actually). What (I think J) I need is a set of flights that I can reuse, in a Background: given section, by all of these features and scenarios, that is defined in a way that is reusable and visible in each of the feature definitions. Is this possible? Is there a better way to do this? Example: Feature: Delay flights with down line adjustments As a flight scheduler I want to delay a flight and have the down line flights adjusted for different periods So I can more quickly update a schedule when events happen Background: Given I have the following flights scheduled: |aircraft | flight number | dept date | dept time | | XX1 | XX0001 | 03Mar2009 | 1000 | | XX1 | XX0002 | 03Mar2009 | 1400 | | XX1 | XX0003 | 03Mar2009 | 2100 | | XX1 | XX0004 | 04Mar2009 | 1000 | Scenario: delay flights with down line adjustments for same dept date as delayed flight When I delay flight XX001 by 5 mins Then XX001 departs at 1005 Then XX002 departs at 1405 Then XX003 departs at 2105 Then XX004 departs at 1000 OR Scenario: delay flights with down line adjustments for same dept date as delayed flight When I delay flight XX001 by 5 mins Then the scheduled flight should be |aircraft | flight number | dept date | dept time | | XX1 | XX0001 | 03Mar2009 | 1005 | | XX1 | XX0002 | 03Mar2009 | 1405 | | XX1 | XX0003 | 03Mar2009 | 2105 | | XX1 | XX0004 | 04Mar2009 | 1000 | There are many more scenarios. Is there a nice way to removed the duplication that is here, especially since I will need a similar set of flights for other scheduling change scenarios? Does anyone see a nice way to simplify the scenarios? Great tool by the way. Thanks, Wes Have you seen this? http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/ Another way to remove duplication (and noise) from Cucumber steps is the hide the details in the Ruby code that implements the step, and write a much more general step in the feature file like this: Given there are 3 flights departing on the same day And the flights all leave at different times And there is another flight leaving on the following day When the earliest flight is delayed by 5 mins Then the flights on the first day should all be delayed by 5 minutes And the flight on the second day should be unaffected These kind of steps can be clearer to read, but the trade-off is that your underlying step code gets more complex as you start writing logic to deliver these specific scenarios. Still, if you're clever about it, these 'declarative' steps can still be pretty re-usable. HTH, Matt
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
