Controller tests make less sense in Rails 3 stack. For example, you cannot assert the proper HTTP headers in some cases because they are being set in a middleware, not in the controller. So while you can assert **some** of the behavior in the controller, I personally prefer it to go through my middleware stack. I reserve the (few) controller tests for fail fast tests, often using stubs to isolate the controller. In my talk to Chelimsky, we both noted this is a common subject of confusion to newcomers, but that’s another discussion.

—

I don’t get this. Isn’t this what controller tests are for?

> Are you thinking there’s nothing else we need from Rails for a Capy-specific type of group?

Exactly. I cannot think of anything Rails would need to do. In my opinion, all we need from RSpec Rails is to generate a spec/features directory on install and document its purpose. Capybara would then register the appropriate hooks, as it does for spec/acceptance.

I agree this is a blurry area, that’s why we just need to talk about each gem responsibility, because today’s issue comes exactly from Capybara and RSpec giving different roles to the same example group (i.e. spec/requests).