All,
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
Subject: [rspec-users] Reuse of Cucumber Features
+lots 
Generally when we have problems with features its because we are trying
to
do to much at once. So in your case date entry is being complicated by
different contexts, birth and incident. One of the tennents of BDD is to
write the simplest thing you can to make you feature pass. I think
another
one should be “first of all write the simplest scenarios”. So taking one
of
your examples
Scenario: Enter Valid Incident
When I fill incident correctly
I should recieve a confirmation
Then your incident step can be something like
When /^I fill incident correctly$/ do
fill_in(“incident[name]”, :with => …
…
end
If you wanted to specify validation in features you could do a step like
When /^I fill incident correctly except$/ do |field|
When “I fill in incident correctly”
fill_in(“incident[#{field}]”, :with => ‘’
end
now you can create new features like
Scenario: Enter Valid Incident with no date
When I fill incident correctly except date
I should recieve an error
With a bit more trickery you could have
When I fill incident correctly except date which is xxx
Taking this approach you can build incrementally quite complex
validation
features whilst stll keeping each scenario simple and focused on one
thing.
Whether you should do this with features or put this detail somewhere
else
is another question entirely.
On another point with dates have you considered international issues.
All
the dates you’ve given in your example are valid (technically) there
just
not in the format you prefer. Also consider that the invalidity of
dates
might be context dependant e.g. an incident date in the future, an
appointment in the past.
HTH
Andrew
2008/12/14 Pat M. <pergesu at gmail.com
http://rubyforge.org/mailman/listinfo/rspec-users >
Hi Steve,
I likely would only write two scenarios, one for a valid date and one
for an invalid one. Then I would write object-level specs to
determine
patient and incident features. Same idea as the first paragraph, but
using features instead of specs.
Pat
“Steve M.” <stevemolitor at gmail.com
http://rubyforge.org/mailman/listinfo/rspec-users > writes:
Thanks – that gets me closer. Here’s an example. Let’s say I have
two
features, ‘Create new patient’ and ‘Create new incident’. To
create a new patient you have to enter a valid birth date. To
create a
new patient you must enter a valid birth date. To create a new
incident you must enter a valid incident date. The rules for date
entry
I should see “Invalid date…”
Given the above, how should I write the ‘create new patient’ and
‘create
new incident’ features? I don’t want to copy and paste all the
date related scenarios, but I do want to specify (and test) that the
patient birth date and incident date fields conform to the general
date
rules. Here’s how the ‘create new patient’ and ‘create new
incident’
Scenario: Enter valid birth date, valid name
Scenario: Enter invalid incident date
Scenario: Enter valid incident date with dashes…
Am I making sense? I want to specify the date in the features, as
there
may be extra requirements like birth dates can not be in the future
in addition to the generic date requirements. And I want to
validate
that the form checks for valid dates, displays the appropriate error
message when invalid, and uses the common rules for parsing. But I
don’t
want to copy and paste those scenarios in every feature. I think
reusing steps as you mention is probably the solution but I’m stuck
on
how to word it and put it together in my case.
Steve
On Sun, Dec 14, 2008 at 8:41 AM, Matt W. <matt at mattwynne.net
http://rubyforge.org/mailman/listinfo/rspec-users > wrote:
On 13 Dec 2008, at 20:58, Steve M. wrote:
What's the best way to handle a requirement that shows up as
a
sub-requirement requirement in other features? For example let’s say
users can enter dates in various forms throughout my
application.
There is one set of global rules specifying the formats in which
dates may be entered, and how they are interpreted. I put
that
in one feature. In various other features, like 'Create new
patient', one can enter dates, like the patient's birth
date. I
Matt W.
http://blog.mattwynne.net <http://blog.mattwynne.net>
http://www.songkick.com
_______________________________________________
rspec-users mailing list
rspec-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
http://rubyforge.org/mailman/listinfo/rspec-users
rspec-users mailing list
rspec-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
http://rubyforge.org/mailman/listinfo/rspec-users
rspec-users mailing list
rspec-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users