Forum: RSpec Then I should be on /users/3/posts/8/comments/2/edit

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Gavin H. (Guest)
on 2009-04-10 07:14
"Then I should be on /users/3/posts/8/comments/2/edit"

What's the solution for parsing out and matching and arbitrarily deep
nested route?
Gavin H. (Guest)
on 2009-04-10 07:27
The problem is actually this:

And I fill in ...
And I press "Create Comment"
Then I should be on [the correct page, ie.
/users/3/posts/8/comments/2/edit]

How do you write a step for that?
Ben M. (Guest)
on 2009-04-10 09:23
(Received via mailing list)
Gavin H. wrote:
> The problem is actually this:
>
> And I fill in ...
> And I press "Create Comment"
> Then I should be on [the correct page, ie.
> /users/3/posts/8/comments/2/edit]
>
> How do you write a step for that?
>
I just saw this second message.. My assumption about what you were
testing was off, but the principle remains the same.  You should verify
that the application is correct by looking at what the user actually
sees in the response body- not what they see in the URL/address bar.

So, instead of saying "Then I should be on..." can you say something
like "Then I should see..."?  Again, does the user really care what the
URL is, or what is actually on the page?

-Ben
Josh K. (Guest)
on 2009-04-10 09:25
(Received via mailing list)
On Thu, Apr 9, 2009 at 11:27 PM, Gavin H. <removed_email_address@domain.invalid>
wrote:
> The problem is actually this:
>
> And I fill in ...
> And I press "Create Comment"
> Then I should be on [the correct page, ie.
> /users/3/posts/8/comments/2/edit]
>
> How do you write a step for that?

Personally I try and stay away from step-matchers based on URLs. Do
you really care about what page you're on?

I would instead check the response for the "Thank you for posting" or
whatever message that you're probably showing.

If however you want to check the page, do something like
response.url.should == "/blah"



--
Josh K.
phone: 509-979-1593
email:  removed_email_address@domain.invalid
web:    http://joshknowles.com
Gavin H. (Guest)
on 2009-04-10 09:32
Ben, Josh

Makes perfect sense.  The user won't be looking at the URL.  He'll
expect some result on the page, thus we test for that.

Thanks!

Gavin
Pat M. (Guest)
on 2009-04-10 09:33
(Received via mailing list)
I'm not sure, cause I've never tried to write a step like that.

I would rather do
Then I should see "Editing 'My sweet comment'"

Even better would be to actually edit the comment and make sure that
it changed.  So maybe

When I edit the comment to be "My new comment"
Then I should see "My new comment"
And I should not see "My old comment"

This way you're testing the feature itself, rather than some
implementation detail such as the current url.

Pat
Ben M. (Guest)
on 2009-04-10 09:43
(Received via mailing list)
Gavin H. wrote:
> "Then I should be on /users/3/posts/8/comments/2/edit"
>
> What's the solution for parsing out and matching and arbitrarily deep
> nested route?
>
Hi Gavin,
Let me try to answer your question without actually answering it. :)

I generally don't test my URLs.  IMO, for the majority of cases the URL
is merely an implementation detail of the application.  For example I
could easily see the URL in your example
(/users/3/posts/8/comments/2/edit) as being "/posts/8/comments/2/edit"
or "/comments/2/edit" or "/posts/the-name/comments/2/edit".  The user
would be fine with all of these cases, they really don't care one way or
the other.  Instead of focusing on an implementation detail of the
application scenarios should be focused on the behaviour that the user
would like to see.  In your particular case what the user really cares
about is being able to edit a comment, correct?  So, instead of just
verifying that the user is on the right page after clicking on "Edit
Comment", you should have the user actually fill out the form to edit
the comment.  Then verify that the comment is actually updated on the
post's page after they submit the comment editing form.  Off the top of
my head something like this may work:

  Scenario: edit comment
    Given a post exists named "big news"
    And I have made a comment "bad post!" on the "big news" post
    And I am viewing the "big news" post

    When I change my "bad post!" comment to "Great post!"
    And press "Update Comment"

    Then I should see "Great Post!"

With this you are just testing the behaviour of the application. (BTW,
you could write the scenario above number of ways and still be testing
the same thing- I'm not sure if I love the way I wrote it....) You could
change your URL naming scheme and this would still pass because the
behaviour hasn't changed.  By embedding the URL in the scenario your URL
scheme is now coupled to your features unnecessarily.

Sorry, for not really answering your question but I think you will thank
me later if you take this approach. :)


-Ben
Lenny M. (Guest)
on 2009-04-10 19:53
(Received via mailing list)
On Apr 10, 2009, at 12:51 AM, Ben M. wrote:

> URL is merely an implementation detail of the application.  For
> out the form to edit the comment.  Then verify that the comment is
> actually updated on the post's page after they submit the comment
> editing form.

One place I've actually been interested in testing URLs was to verify
that the app actually redirected after a form submission. The user
facing reason for this is to verify that the app works as
expected(e.g. doesn't repost a comment or something) when the user
refreshes to get fresh data. Of course, sticking to what the user
cares about, it would probably be best to have this tested in a
separate scenario for 'user refreshes page after posting comment' .

-lenny
Pat M. (Guest)
on 2009-04-10 20:43
(Received via mailing list)
On Fri, Apr 10, 2009 at 8:49 AM, Lenny M. <removed_email_address@domain.invalid> 
wrote:
>> Hi Gavin,
>> the user really cares about is being able to edit a comment, correct?  So,
> this tested in a separate scenario for 'user refreshes page after posting
> comment' .

I would just test that at the controller level

it "should redirect to the comment's article" do
  post :create, :article_id => @article.to_param, :comment => {:body =>
"wooo"}
  response.should redirect_to(@article)
end

Pat
Pat M. (Guest)
on 2009-04-10 20:47
(Received via mailing list)
On Fri, Apr 10, 2009 at 9:40 AM, Pat M. <removed_email_address@domain.invalid>
wrote:
> I would just test that at the controller level

I would _specify_ that at the controller level.

BAD BDD evangelist :P
Stephen E. (Guest)
on 2009-04-11 07:51
(Received via mailing list)
On Fri, Apr 10, 2009 at 11:49 AM, Lenny M. 
<removed_email_address@domain.invalid> wrote:
>
> One place I've actually been interested in testing URLs was to verify that
> the app actually redirected after a form submission.

I can agree with this, and I had a similar need just the other day.  I
had an action that redirected to different places depending on whether
a certain box was checked.  But I didn't spec it by checking the
literal text of URL itself.  Instead I worked with the paths
functionality that was already in Cucumber's support directory, and
made it a bit more flexible.  Here was my situation:

 Scenario: Has an Enclosure
   Given I am a contributor
    When I go to the create episode page
     And I fill in [...blah blah, submitting the form...]
    Then I should have an episode titled "Any title"
     And I should be on the create enclosure page for that episode

...I wanted that "I should be on (foo) for that (bar)" to be general,
so in my application_steps.rb:


Then /^I should be on (.*page) for that (.*)$/ do |page, element|
  current_url.should == path_to(page,
instance_variable_get("@#{element}"))
end

...And finally, I rewrote the path_to method in paths.rb a bit:

  def path_to(page_name, parent_object = nil)
    case page_name
    [ . . . ]
    when /the create enclosure page/i
      new_episode_enclosure_url(parent_object)

This all worked, and it worked well.  Though of course, going through
the work of specing and building a separate enclosure model made me
decide that it would really work better as a simple Paperclip
attribute inside episode, so I threw all that away...  But c'est la
vie.  >8->



--
Have Fun,
   Steve E. (removed_email_address@domain.invalid)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
This topic is locked and can not be replied to.