[rspec-users] stepping across features

Andrew Premdas apremdas at gmail.com
Mon Dec 8 18:20:43 EST 2008


Glad to be of some use. I think you're getting stuff, and your questions are
helping me get stuff and clarify some thoughts as well so thankyou for that.



2008/12/8 James Byrne <lists at ruby-forum.com>

> Andrew Premdas wrote:
> >
> > TIp: When writing the step don't use  - visits "/invoices/new" - use
> > visits "invoice_new_path". Use named routes and let the routing names
> > REST and resources define where you go, and think about what you want
> > to implement
>
> This advice is really helpful.  I was reading the section on routing in
> "The Rails Way" last night, and it came to me that perhaps I had
> overlooked the essence of what I was really trying to accomplish.  That
> I was so fixated on the code yet to be produced at the detail level that
> I had missed the boat with respect to how the users would treat the
> application as a whole.  I concluded that I really needed to see the new
> application, and the features that I had to write, in terms of
> resources.  Then, given the resource name, the requisite information
> would be exposed.  This in turn would expose the requirements needed to
> assemble that information from data, and from those assembly
> requirements would come the code requirements.
>
> However, I was, until I read your reply, still thinking in terms of
> "/application/clients/:myclient/workorders/:id/charges/:billable"
> instead of
> client_workorder_charges_path(@client, at client.workorders,"billable") or
> however that is supposed to be expressed.
>
> >
> > If you now deal with your charges, you will probably get to the stage
> > very quickly where you can't avoid clients. So then you do the very
> > simplest general thing for clients.
>
> It is impossible to undo the past.  We have already invested a
> considerable amount of energy and time into determining how we wish to
> express the concept of a client as a transient role of some persistent
> entity rather than as an artifact in itself.  But, that said, I am
> beginning to see that this can be set aside in the early stages.
>
> >
> > Finally every time you find that the baby step you are taking is
> > actually more like a giant leap (or actually anything other than
> > the smallest of steps) STOP!  Then start again questioning what
> > is not central and what is not specific.
> >
> > HTH
>
> Very helpful.  I expect that as I gather my wits regarding BDD that this
> advice will prove even more valuable.
>
> I tried a little bit of this out on one of the end users and I was
> surprised at the responses that I obtained.  In consequence, this is
> what I contemplate beginning with.
>
> Feature: A web based business application
> In Order To: Conduct Business
> Any Authorized User
> Should Access the Business Application via http
> To reduce costs
>
>  Scenario: The Application has a home page
>    Given an application accessible by http
>      And I am not signed in
>    When I browse to the url "/" on the application host
>    Then I should see a welcome message
>      And I should see a sign on request message
>      And I should see a sign on link
>      And I should see a contact us link
>      And I should see ...
>
>  Scenario: The Application has a sign on page
>    Given I am on the home page
>      And I am not signed in
>    When I select the sign on link
>    Then I should see the sign on page
>      And the protocol should be https
>      And I should see a text entry for user name
>      And I should see a text entry for password
>      And I should see a sign on action selector
>
>  Scenario: User Signs On Successfully
>    Given I am on the sign on page
>      And I am not signed in
>      And I have a user named "myuser"
>      And the user named "myuser" has a password of "myuserpassword"
>    When I provide a user name "myuser"
>      And I provide a password "myuserpassword"
>      And I select the sign on action
>    Then I should see a sign on success message
>      And I should see the users home page
>
>  Scenario: User Sign On Fails - wrong password
>   ...
>  Scenario: User Sign On Fails - no such user
>   ...
>  Scenario: User Sign On Fails - more than 3 attempts in 20 seconds
>   ...
>
> Then we have identified a new feature, the user home page.  Also, one
> can foresee that additional scenarios are required, like "User Signs in
> >From a Secured Resource" where following a successful sign in the user
> is redirected back to the resource that they originally requested. On
> the users home page we discover the resources accessible by that user
> are listed.  From those resources the next layer of features become
> exposed, and so on.
>
> Is this getting closer to the mark or am I moving around the target but
> not quite getting it?
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081208/15754232/attachment-0001.html>


More information about the rspec-users mailing list