[rspec-users] Reuse of Cucumber Features

Williams, Wesley Wesley.Williams at sabre.com
Thu Apr 9 09:22:20 EDT 2009



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?





From: rspec-users-bounces at rubyforge.org [mailto:rspec-users-bounces at 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?
		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
		     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
		  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.


	Have you seen this?
	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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090409/d91bcbfd/attachment-0001.html>

More information about the rspec-users mailing list