[rspec-users] Reuse of Cucumber Features

Matthew Krom matthew.krom at gmail.com
Thu Apr 9 08:43:35 EDT 2009


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


More information about the rspec-users mailing list