rondy/request_vs_controller.md

## request_vs_controller.md

      
    Raw
  

              request_vs_controller.md
            
          
    Requests specs x controller specs

Despite of they feel to be almost the same, there is a subtle difference between them: In request specs, you can exercise the full stack of a HTTP request (from routing to the view layer, so to speak).
Request specs also allows you to access more than one endpoint at a time, so you are able to test a whole scenario’s flow, whereas in controller specs you can exercise only one endpoint per test case (i.e., a single controller’s action).
# request spec
specify do
  get '/my-first/enpoint'
  post '/create-some-resource'
  follow_redirect!
  get '/my-last/enpoint'
end

# controller spec
specify do
  get :new
end
Given the snippet above, one could then consider requests specs for integration-test purposes (where you strive for more collaboration), and controller specs for unit-test purposes (for more specialization).
It would also be reasonable to compare them to the parallel between feature (acceptance) specs x view specs, from a UI testing perspective.
When to use request specs?

Whenever you need to have some confidence level of a integration flow, mainly in the ones that are not aimed to human users (i.e., there will not be interactions from the browser), or there are some routing constraint involved (e.g., ENV variables dependency, subdomain rules, etc).
I also find that they’re more conceptually suited for testing JSON API responses (I can expand my arguments on this last sentence later).