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 want to do something like ''and the date entry shall follow the normal rules'' but I''m not sure how to do that in an example driven way, without copying and pasting from other features. Does my question make sense? Any suggestions? Thanks. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <rubyforge.org/pipermail/rspec-users/attachments/20081213/039f57d5/attachment.html>
On 13 Dec 2008, at 20:58, Steve Molitor 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 want to do > something like ''and the date entry shall follow the normal rules'' > but I''m not sure how to do that in an example driven way, without > copying and pasting from other features. > > Does my question make sense? Any suggestions?Do you know that you can call steps within steps? blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps Is that what you''re looking for? Matt Wynne blog.mattwynne.net songkick.com
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 are the same: Feature: Date entry Scenario: Invalid month When I fill in the date value with "13/01/2000" I should see "Invalid date..." Scenario: Invalid year (not 4 digits) When I fill in the date value with "13/01/00" I should see "Invalid date..." Scenario: Separate with slashes (ok) When I fill in the date value with "01/13/2000" I should see "valid date..." Scenario: Separate with dashes (ok) When I fill in the date value with "01-13-2000" I should see "valid date..." .... etc.... 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'' features would look with some copy and pasting: Feature: Create new Patient Scenario: Enter invalid birth date Given I fill in "birth date" with "13/01/2000" And I fill in "patient name" with "Sam Smith" When I press "Save" I should see "Invalid birth date ''13/01/2000''" Scenario: Enter valid birth date, valid name Given I fill in "birth date" with "01/13/2000" And I fill in "patient name" with "Sam Smith" When I press "Save" I should see "Patient Created Successfully" Scenario: Enter valid birth date with dashses..... ------- Feature: Create new Incident Scenario: Enter invalid incident date Given I fill in "incident" with "13/01/2000" And I fill in "supervisor" with "Sam Smith" When I press "Save" I should see "Invalid incident date ''13/01/2000''" Scenario: Enter valid incident date, valid supervisor Given I fill in "incident date" with "01/13/2000" And I fill in "supervisor" with "Sam Smith" When I press "Save" I should see "Incident Created Successfully" 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 Wynne <matt at mattwynne.net> wrote:> > On 13 Dec 2008, at 20:58, Steve Molitor 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 want to do something like ''and the date entry shall follow >> the normal rules'' but I''m not sure how to do that in an example driven way, >> without copying and pasting from other features. >> >> Does my question make sense? Any suggestions? >> > > Do you know that you can call steps within steps? > blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps > > Is that what you''re looking for? > > Matt Wynne > blog.mattwynne.net > songkick.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <rubyforge.org/pipermail/rspec-users/attachments/20081214/f229a8a7/attachment.html>
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 what a valid date is. Extract this to a validator that you can reuse throughout your model. If it''s important that you write features for each potential invalid date format (because you want to communicate them with the customer) then I would write a feature file similar to what you show...but it would be focused only on the date, I wouldn''t mention patients or incidents at all. Date entry seems to be an important concept in your application, so I would write one feature that specifies how I expect date entry to work, and then I can just write valid/invalid dates for patient and incident features. Same idea as the first paragraph, but using features instead of specs. Pat "Steve Molitor" <stevemolitor at gmail.com> 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 are the same: > > Feature: Date entry > > Scenario: Invalid month > When I fill in the date value with "13/01/2000" > I should see "Invalid date..." > > Scenario: Invalid year (not 4 digits) > When I fill in the date value with "13/01/00" > I should see "Invalid date..." > > Scenario: Separate with slashes (ok) > When I fill in the date value with "01/13/2000" > I should see "valid date..." > > Scenario: Separate with dashes (ok) > When I fill in the date value with "01-13-2000" > I should see "valid date..." > > .... etc.... > > 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'' features would look with some copy and pasting: > > Feature: Create new Patient > > Scenario: Enter invalid birth date > Given I fill in "birth date" with "13/01/2000" > And I fill in "patient name" with "Sam Smith" > When I press "Save" > I should see "Invalid birth date ''13/01/2000''" > > Scenario: Enter valid birth date, valid name > Given I fill in "birth date" with "01/13/2000" > And I fill in "patient name" with "Sam Smith" > When I press "Save" > I should see "Patient Created Successfully" > > Scenario: Enter valid birth date with dashses..... > ------- > > Feature: Create new Incident > > Scenario: Enter invalid incident date > Given I fill in "incident" with "13/01/2000" > And I fill in "supervisor" with "Sam Smith" > When I press "Save" > I should see "Invalid incident date ''13/01/2000''" > > Scenario: Enter valid incident date, valid supervisor > Given I fill in "incident date" with "01/13/2000" > And I fill in "supervisor" with "Sam Smith" > When I press "Save" > I should see "Incident Created Successfully" > > 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 Wynne <matt at mattwynne.net> wrote: > > On 13 Dec 2008, at 20:58, Steve Molitor 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 want to do something like ''and the date entry shall follow the > normal rules'' but I''m not sure how to do that in an example driven way, without copying and pasting from other features. > > Does my question make sense? Any suggestions? > > Do you know that you can call steps within steps? > blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps > > Is that what you''re looking for? > > Matt Wynne > blog.mattwynne.net > songkick.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > rubyforge.org/mailman/listinfo/rspec-users
+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 Maddox <pergesu at gmail.com>> 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 > what a valid date is. Extract this to a validator that you can reuse > throughout your model. > > If it''s important that you write features for each potential invalid > date format (because you want to communicate them with the customer) > then I would write a feature file similar to what you show...but it > would be focused only on the date, I wouldn''t mention patients or > incidents at all. Date entry seems to be an important concept in your > application, so I would write one feature that specifies how I expect > date entry to work, and then I can just write valid/invalid dates for > patient and incident features. Same idea as the first paragraph, but > using features instead of specs. > > Pat > > > "Steve Molitor" <stevemolitor at gmail.com> 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 > are the same: > > > > Feature: Date entry > > > > Scenario: Invalid month > > When I fill in the date value with "13/01/2000" > > I should see "Invalid date..." > > > > Scenario: Invalid year (not 4 digits) > > When I fill in the date value with "13/01/00" > > I should see "Invalid date..." > > > > Scenario: Separate with slashes (ok) > > When I fill in the date value with "01/13/2000" > > I should see "valid date..." > > > > Scenario: Separate with dashes (ok) > > When I fill in the date value with "01-13-2000" > > I should see "valid date..." > > > > .... etc.... > > > > 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'' > features would look with some copy and pasting: > > > > Feature: Create new Patient > > > > Scenario: Enter invalid birth date > > Given I fill in "birth date" with "13/01/2000" > > And I fill in "patient name" with "Sam Smith" > > When I press "Save" > > I should see "Invalid birth date ''13/01/2000''" > > > > Scenario: Enter valid birth date, valid name > > Given I fill in "birth date" with "01/13/2000" > > And I fill in "patient name" with "Sam Smith" > > When I press "Save" > > I should see "Patient Created Successfully" > > > > Scenario: Enter valid birth date with dashses..... > > ------- > > > > Feature: Create new Incident > > > > Scenario: Enter invalid incident date > > Given I fill in "incident" with "13/01/2000" > > And I fill in "supervisor" with "Sam Smith" > > When I press "Save" > > I should see "Invalid incident date ''13/01/2000''" > > > > Scenario: Enter valid incident date, valid supervisor > > Given I fill in "incident date" with "01/13/2000" > > And I fill in "supervisor" with "Sam Smith" > > When I press "Save" > > I should see "Incident Created Successfully" > > > > 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 Wynne <matt at mattwynne.net> wrote: > > > > On 13 Dec 2008, at 20:58, Steve Molitor 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 > want to do something like ''and the date entry shall follow the > > normal rules'' but I''m not sure how to do that in an example > driven way, without copying and pasting from other features. > > > > Does my question make sense? Any suggestions? > > > > Do you know that you can call steps within steps? > > blog.mattwynne.net/2008/11/14/dry-up-your-cucumber-steps > > > > Is that what you''re looking for? > > > > Matt Wynne > > blog.mattwynne.net > > songkick.com > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <rubyforge.org/pipermail/rspec-users/attachments/20081216/cdfd6814/attachment.html>