Starr H. [email protected] writes:
What does people do here? ignore the fact that the integration test
generate HTTP request which differs from what a broswer will do, or do
you use post (or post_via_redirect) and adding the “_method” parameter
manually.
I think you’re just splitting hairs at that point. If the put request in your integration test doesn’t get routed to the correct action, the test will fail anyway.
Hi Starr.
Thanks for taking your time to answer my post.
I think you misunderstand. My put request in my integration test do
get routed to the correct action. My point is a standard browser will
not generate HTTP PUT request upon edits, so my integration test does
not reflect standard usage of my web-app.
rake routes show:
edit_order GET /orders/:id/edit(.:format)
{:controller=>“orders”, :action=>“edit”}
PUT /orders/:id(.:format)
{:controller=>“orders”, :action=>“update”}
However the default (which I use) view (app/views/order/edit.html.erb
contains
<% form_for(@order) do |f| %>
And one should expect this to generate HTML that upon commit makes a
HTTP PUT request to the update action.
However the above form_for(@order) call generates the following HTML
form:
So even though I tell rails that I want the update action to use the
HTTP PUT request, the generated HTML in the edit.html.erb is form
generating a HTTP POST request with an additional hidden input named
“_method” with the value “put”
That means, that when people are using the app from a standard
browser the browser will send a HTTP POST request.
First of all I wonder why rails (the form_for method) does not
generate a form that will send a HTTP PUT request. I think (but this
is only a wild guess) this is because it is work-in-progress
Secondly, now the situation is like that, what does people do (in
their integration test) to accommodate for the situation.
Basically I don’t have a problem with my application. I just see that
my integration tests does not generate the HTTP requests that a real
browser would have done.
Jarl