On Tue, Jan 5, 2010 at 11:37 AM, Ashley Moran <[email protected] > wrote:
> > On Dec 30, 2009, at 3:52 pm, Francis Fish wrote: > > > Given I am logged in as an admin user > > And I am in the blah area > > When I select edit blah > > Then I will see the edit blah screen > > > > Then I want to be able to create some way of saying I can edit a field or > fields of a blah. > > > > I've created something like this: > > > > Scenario Outline: create blah details > > Given I am logged in as a creator > > And I am creating a blah > > Then I can input the value of <field> > > > > Scenarios: blah fields > > | field | > > | Name | > > | Description | > > > > It just seems a little primitive and repetitive for something that's on > release 10 or so and the linking of named artefacts ever so slightly opaque > and magic spell. I want to put all of this in one description, basically all > the CRUD and index stuff without having to repeat myself over and over > again. > > Hi Francis > > Well Andrew's nudged me into replying, and this is the stuff I allegedly do > for a living after all :) > > BTW, not watched that Cucumber video in case I duplicate stuff on it. > > I have settled on a fairly standard template for CRUDL - that's CRUD + > List. Used as a verb, eg the bizarrely sinister-sounding phrase from my > most recent project - "let's crudl some children". I've included a > sanitised example below. > > Doug's example is fine, in terms of getting multiple fields into one > scenario run. (Which avoids repeated background setup.) But you can go a > step further and put the data horizontally. This lets you write steps to > bulk-create data, eg: > > Given the following times table facts: > | Multiplicand | Multiplier | > | 5 | 2 | > | 5 | 3 | > | 5 | 4 | > | 5 | 5 | > > Note that that step is almost entirely generic, and everything after "Given > the following..." is only used to get on the right page in the first place. > The form submission code doesn't actually know what it's creating. > > Also, be sure to focus on the ultimate goal of the user in the interaction. > It's unlikely the user is concerned with being able to edit fields; rather, > they want to keep some data current for some reason. This takes the steps > from "Then I can input the value of <field>" closer to "When I have > submitted <field>; Then I should see <field> updated" or some such. > Although, CRUDL is at such a low level that this example may seem > contrived. > > Another way to look at this is that the _ability_ to do something is > implicit in the fact that _doing it_ produces the correct output. So if > submitting the form produces the desired effect, then submitting the form is > clearly possible, and it's not (usually) necessary to check for signs that > it might be possible. (This strategy relies on making the steps print good > diagnostic info when something goes wrong.) > > HTH. Let me know if you have any questions. > > Ashley > > > Feature: Administrator updates ENTITYs > So that I can define how OTHER ENTITY is presented > As an Administrator > I want to update an ENTITY > > Scenario: Viewing update page > Given the following ENTITY: > | Name | Style | Replacement | > | Standard | L-R-R | R | > And I have logged in as '[email protected]' > When I visit the Edit 'Standard' ENTITY page > Then I should see 'Edit ENTITY' > > Scenario: Successful update > Given the following ENTITY: > | Name | Style | Replacement | > | Standard | L-R-R | R | > And I have logged in as '[email protected]' > When I visit the Edit 'Standard' ENTITY page > And I update an ENTITY by submitting the following details: > | Name | Style | Replacement | > | Commutative | R-L-R | R | > Then I should be taken to the 'Commutative' ENTITY page > And I should see 'updated successfully' > And I should see the following ENTITY details: > | Name | Style | Replacement | > | Commutative | R-L-R | R | > > Scenario: Unsuccessful update with missing name > Given the following ENTITY: > | Name | Style | Replacement | > | Standard | L-R-R | R | > And I have logged in as '[email protected]' > When I visit the Edit 'Standard' ENTITY page > And I update an ENTITY by submitting the following details: > | Name | Style | Replacement | > | | L-R-R | R | > Then I should see 'Edit ENTITY' > And I should see 'Couldn't update ENTITY' > And I should see 'Name must not be blank' > > > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > -- > > You received this message because you are subscribed to the Google Groups > "NWRUG" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nwrug-members%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nwrug-members?hl=en. > > > Thanks for this Ashley, I think I need to do some deeper and wider scenarios that blank out mandatory fields like you suggest. Needs some thought. I've come up with this, thus far but I think I will work on it using your suggestions. Even now, just looking at it before pasting it in I can see things wrong with it, as in too many steps. I'm being lazy and using Background. There is no background rspec for any of this because I want to write the specification first for discussion with my business partner so changing it is easy. Measure twice, cut once. Feature: creator manages doodads As a creator I want to be able to create, retrieve, update and delete doodads So that I can manage doodads Creator can see doodads that they created or have been published Creator can edit a doodad belonging to someone else and the edit belongs to them Once published doodads can be archived and not deleted and are still visible Background: Given I am logged in as a creator And I am in the manage doodads area Scenario: creator creates doodad When I have selected the create doodad action Then I should see the create doodad screen And I can input the following fields | field | | Description | | Blah | Scenario: creator deletes doodad When I have selected a doodad And the doodad can be deleted And I have clicked delete Then I should see the deletion confirmation Scenario: creator edits doodad When I have selected a doodad And the doodad can be edited And I have clicked edit Then I should see the edit doodad screen And I can edit the following fields | field | | Description | | Blah | Scenario: creator views doodad details When I have selected a doodad And I have clicked details Then I should see the doodad details screen Scenario: creator views list of doodads When I have selected view doodads And I have put in selection criteria Then I should see a list of doodads And they will match the criteria And I will have created them or they will be published Scenario: creator cannot delete published doodad And a doodad has been published Then I should not be able to delete it Scenario: creator publishes doodad When a doodad is unpublished Then I should be able to publish it Thanks and regards, Francis Follow me on twitter https://twitter.com/fjfish Blog at http://www.francisfish.com (you can also buy my books from there!) Skype: fjfish My other sig is much funnier and world changing but I can't find it anywhere--
You received this message because you are subscribed to the Google Groups "NWRUG" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
