Feature Requests item #6059, was opened at 2006-10-08 01:54
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6059&group_id=797
Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: David Lee (davidlee)
Assigned to: Nobody (None)
Summary: Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block
Initial Comment:
Controller testing with RSpec + Rails: response is not upated within a specification when same action is called multiple times within a specify block
using Rails 1.1.6 and RSpec 0.6.4
The response object is not being updated within a specify block if multiple responses are generated by GETting the same action.
This was verified by checking the redirect_url reported.
This does not appear to be an issue unless the *same action* is called multiple times within a specify block, eg to test the effect of accessing an action with different permissions or parameters. Calling the action with different parameters did not appear to affect the problem.
example:
specify "Index should redirect to welcome if already logged in" do
# this will redirect to login as user is not logged in.
# the presence of this line will break the test.
get :index
request.session[:user] = 1 # subsequent gets will redirect to welcome
# this will be ignored with regard to the response.redirect_url reported
get :index
response.should_redirect
# fails if first line is present:
# says the redirect_url equals 'http://test.host/account/login'
# which is a leftover from the first get :index
response.redirect_url.should_equal 'http://test.host/account/welcome'
end
breaking the two `get :index` calls out into separate specify blocks alleviates the problem.
----------------------------------------------------------------------
Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:34
Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/21-6059-controller-testing-w-rails-response-is-not-upated-when-same-action-is-getted-multiple-times-within-a-specify-block#ticket-21-2
----------------------------------------------------------------------
Comment By: Assaf Arkin (assaf)
Date: 2007-09-12 23:50
Message:
Given
GET request returning Last-Modified
When
GET request uses it as If-Unmodified-Since
Then
304 (Not Modified)
But due to this design, I'm going to receive 200 the second time. Note that I don't care to mock the value of Last-Modified, this is the expected behavior of the controller.
Or:
Given
PUT entity in resource
When
GET entity from resource
Then
200 (OK)
and entities are equivalent
But if PUT returns 201 (Created), then so will GET. Again, I do not care to mock the model, it's too much work to get the model to match the output, when neither mock nor model are the behavior I'm testing here.
I think controller specs that can only issue one request are too fine grained. It's the equivalent of model specs where you can create or find or update, but not do both in a single sequence.
----------------------------------------------------------------------
Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-07 11:02
Message:
Also - moving this over to feature requests - this is by design, not a bug.
----------------------------------------------------------------------
Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-07 11:02
Message:
"breaking the two `get :index` calls out into separate specify blocks alleviates the problem."
That's also the BDD way.
Given (context)
When (single event or set of events)
Then (outcomes)
The specs could read:
Given a user who is logged in
- GET index should redirect to welcome
Given a user who is NOT logged in
- GET index should redirect to login page
OR you could have two specs in the same context:
GET index
- should redirect a logged in user to welcome
- should redirect an anonymous user to the login page
We will need to support multiple GETS when we add integration specs, so I'll leave this open to keep it on the radar, but we will likely not be supporting this in the context of controller specs.
----------------------------------------------------------------------
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6059&group_id=797