I view the controller tests as I’m only testing what’s in the controller.
I view the integration test as like rails guide says, workflow. View them as lightweight headless system tests. They were excellent to use before Rails had baked in system tests, and you didn’t want to set up Capybara or Watir to do browser testing.
I don’t use this part of Rails – I use RSpec for testing.
I know that in RSpec, people tend to EITHER have controller tests OR request tests (which feel like they’re equivalent to integration tests here).
It sounds like that might also be the case here, people tend to use either one or the other. This might be a case for a stronger default, or just a case for better documentation.
This was the cause of a heated discussion here a few months ago.
Back then, when I was looking for references on the pros and cons, I found out an interesting take on this matter here RSpec 3.5 has been released!
The official recommendation of the Rails team and the RSpec core team is to write request specs instead. Request specs allow you to focus on a single controller action, but unlike controller tests involve the router, the middleware stack, and both rack requests and responses. This adds realism to the test that you are writing, and helps avoid many of the issues that are common in controller specs. In Rails 5, request specs are significantly faster than either request or controller specs were in rails 4, thanks to the work by Eileen Uchitelle1 of the Rails Committer Team.
Even though this is a quote from Rspec, the part where it said that the Rails team recommend request specs caught my attention. As @Betsy said, I also agree that a strong defaut would make much sense and avoid lots of WTFs from new (and also experienced) Rails developers.
Controller tests are not exactly deprecated, both in RSpec, and in Rails core testing, but they are definitely de-emphasized, see What’s up with Rails Controller Tests.