On Apr 10, 2009, at 12:51 AM, Ben Mabey wrote:
Gavin Hughes 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.
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
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
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
