Hi Jonathan.<br><br>You can think of the What's in a Story article as trainer wheels. The point is to start thinking in givens, events and outcomes (ie. which activities in this scenario are setting up context, which are the "interesting bits" and which are verification).
<br><br>Once you are comfortable with this, it is perfectly natural to want multiple steps interleaved. A very common pattern is to have some Givens then repeating sequences of Whens and Thens, which represent various operations through a user scenario. So you might say:
<br><br>Given I am on the login screen<br><br>When I enter my credentials<br>Then I should be on the summaries page<br><br>When I select an entry<br>Then I should see its detail<br><br>When I delete the entry<br>Then I should be back on the summary page
<br>And the deleted entry should have disappeared<br><br>As long as you are aware what each stanza represents ("I should be back on the summary page" is an outcome, "I select an entry" is an event, etc.) then you're definitely on the right lines.
<br><br>I just found a paragraph from the article that might help:<br><br><div style="margin-left: 40px;">"Not all scenarios are this simple. Some are best represented as a sequence of events, described as: <em>given [some context] when [I do something] then [this happens] when [I do another thing] then [this new thing happens]
</em>
and so on. An example is a wizard-style website, where you step through
a sequence of screens to build up a complex data model. It is perfectly
appropriate to intermingle sequences of events and outcomes, as long as
you get into the habit of thinking in these terms."<br></div><br>Thanks,<br>Dan<br><br><br><div><span class="gmail_quote">On 10/3/07, <b class="gmail_sendername">Jonathan Linowes</b> <<a href="mailto:jonathan@parkerhill.com">
jonathan@parkerhill.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Pat,<br><br>Any more thoughts on submit_form and follow_link? I really like that
<br>idea, it fits well with the story concept, imo . And using the links<br>and forms inside the response is better coverage than assuming the<br>entry point to the next page.<br><br>So a scenario becomes a sequence of actions taken by the user to
<br>accomplish a task (however small or large).<br>In which case, could you have multiple When-Then's ? eg from your<br>example<br><br><br>> Scenario "Successful listing" do<br>> Given "A user" do
<br>> User.create! :login => "pat", :password => "password"<br>> end<br>> When "user visits the login page" do<br>> get "/login"<br>> end
<br> Then "user sees login page" do<br> response.should have_text(/Please login/)<br> end<br>> When "user logs in" do<br>> submit_form :login, :login => "pat", :password => "password"
<br>> end<br> Then "page shows Create an auction" do<br> response.should have_tag(...)<br> end<br>> When "user visits new auction page" do<br>> click_link "Create an auction"
<br>> end<br>> When "user creates auction" do<br>> submit_form :auction, :auction => { :item_name => "Ruby for<br>> Rails", :price => 50 }<br>> end<br>> Then "new auction should be listed" do
<br>> response.should have_text(/Item successfully created!/)<br>> response.should have_text(/Ruby for Rails/)<br>> end<br>> end<br><br><br>I realize this goes against <a href="http://dannorth.net/whats-in-a-story">
http://dannorth.net/whats-in-a-story</a> but<br>it seems more correct than putting those actions into Given clauses.<br><br><br>On Sep 25, 2007, at 6:48 PM, Pat Maddox wrote:<br><br>> On 9/25/07, David Chelimsky <<a href="mailto:dchelimsky@gmail.com">
dchelimsky@gmail.com</a>> wrote:<br>>> On 9/25/07, Jonathan Linowes <<a href="mailto:jonathan@parkerhill.com">jonathan@parkerhill.com</a>> wrote:<br>>>> hi,<br>>>><br>>>> I just started fooling around with story runner, thought I'd start
<br>>>> with a dead simple scenario:<br>>>> The first thing I do when describing a site to someone is go to the<br>>>> home page, and begin exploring public pages from there.<br>>>> So, that seems like a good first story to spec out.
<br>>>><br>>>> And I'd really like to extract the actual link from the rendered<br>>>> page<br>>>> (rather than just "assuming" in the spec), but I'm not sure how<br>>>> to do
<br>>>> that<br>>>> Something like:<br>>>><br>>>> # alink = find tag 'div#home-banner-links a ' where<br>>>> content=="About"<br>>>> # url = extract the href attribute from alink
<br>>>> get url<br>>>><br>>>> Here's the story so far: <a href="http://pastie.caboo.se/100810">http://pastie.caboo.se/100810</a><br>>><br>>> Some comments:<br>>><br>
>> The second scenario seems more like the right level of abstraction<br>>> than the first. Using "should render_template" in a Story seems too<br>>> low level to me. What's interesting is what is being displayed, not
<br>>> what template is being used to display it.<br>><br>> I see what you're getting at. I've thought about it a bit myself, and<br>> have decided that expecting a certain template is a pragmatic way of
<br>> knowing that the user is on the right page.<br>><br>><br>>> The second scenario does a nicer job of that.<br>>><br>>> One thing is that you won't be able to use the full URL. RailsStory
<br>>> wraps rails integration tests, which provide access to routing,<br>>> but as<br>>> paths, not URLs. So for href="<a href="http://0.0.0.0:3000/site_pages/about">http://0.0.0.0:3000/site_pages/about
</a>",<br>>> you'd need to extract the "/site_pages/about" part and get that.<br>>><br>>> Thoughts?<br>><br>> I was planning on implementing a<br>> click_link "Follow me!"
<br>><br>> sorta thing in the next couple days. One problem I have is that right<br>> now you still need to know too much about the underlying structure<br>> (and golly if I didn't just contradict the first part of my reply!).
<br>> There was a thread a few days ago [1] where I hinted at that. He<br>> wanted to go directly to a URL, when he should have been following a<br>> redirect.<br>><br>> I think there needs to be some mechanism for following links /
<br>> submitting forms so that you can really follow the path a user takes.<br>> That leaves you with something like:<br>><br>> Story "Create an auction", %{<br>> As a seller<br>> I want to create a new auction
<br>> So that I can get filthy rich<br>> } do<br>><br>> Scenario "Successful listing" do<br>> Given "A user" do<br>> User.create! :login => "pat", :password => "password"
<br>> end<br>> And "user visits the login page" do<br>> get "/login"<br>> end<br>> And "user logs in" do<br>> submit_form :login, :login => "pat", :password => "password"
<br>> end<br>> And "user visits new auction page" do<br>> click_link "Create an auction"<br>> end<br>> When "user creates auction" do<br>> submit_form :auction, :auction => { :item_name => "Ruby for
<br>> Rails", :price => 50 }<br>> end<br>> Then "new auction should be listed" do<br>> response.should have_text(/Item successfully created!/)<br>> response.should have_text(/Ruby for Rails/)
<br>> end<br>> end<br>> end<br>><br>> That requires you to know<br>> 1. Point of entry<br>> 2. IDs of forms and links (or text for links, if you prefer)<br>> 3. The fields that a form uses<br>
><br>> So really all we've gotten away from is dependency on knowing certain<br>> URLs, which I'm not positive is a huge benefit...otoh, this is closer<br>> to tracing a user's path through the app which is nice.
<br>><br>> wdyt?<br>><br>> Pat<br>><br>> [1] <a href="http://rubyforge.org/pipermail/rspec-users/2007-September/">http://rubyforge.org/pipermail/rspec-users/2007-September/</a><br>> 003344.html<br>> _______________________________________________
<br>> rspec-users mailing list<br>> <a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br>> <a href="http://rubyforge.org/mailman/listinfo/rspec-users">http://rubyforge.org/mailman/listinfo/rspec-users
</a><br><br>_______________________________________________<br>rspec-users mailing list<br><a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/rspec-users">
http://rubyforge.org/mailman/listinfo/rspec-users</a><br></blockquote></div><br>