Hi Jon, Thanks for your response. I’m going to assume that you are correct that this test belongs in a request spec, not a controller spec (because the other answer I received had a wrong assumption and did not fix the problem). Philosophically, I guess the purpose of the controller spec is to test that the controller does the things that it is supposed to do, which DOES NOT include default behavior of the Rails/Rack stack. And I guess that request specs are intended to test the operation of the entire system across a given request (or multiple requests that interact). So it makes sense that I should only test things that the controller does, not that it assumes are done for it, in controller specs.
As you can tell, I’m still trying to get my head around exactly what should be tested where. That seems to be at the same time, the single most important concept to understand, and the one with the most subtleties to it. I just took a break in writing this email and started reading about the whole controller tests vs. request tests issue. I’m convinced that request specs are the way to go. So here is my follow-up question: I’m bringing up-to-date a project that was running in Rails 3.1/Rspec2 to more recent and supported versions of those two products. I can see that I’m going to need to replace my controller specs with request specs at some point. The question is when to do it. Right now, I’ve upgraded to Rspec 2.99 and filling in all the missing tests before moving on to a later Rails/RSpec version (per previous recommendations from this list). Is this the time to convert my controller specs into request specs, or are there important features missing from request specs in 2.99 such that I should wait until a later version of Rspec to do that? > On Jul 12, 2020, at 3:05 AM, Jon Rowe <[email protected]> wrote: > > Rails controls the behaviour of its raising / displaying error pages via > config, and by default for test mode it raises. As Phil points out you should > be able to configure this should you wish to test the behaviour directly. > > You might find these need to be request specs for the displaying errors to > work however, as I’m not sure where in the Rails rack stack the middleware > that catches errors is. > > Cheers > Jon Rowe > --------------------------- > [email protected] > jonrowe.co.uk > > On 11 July 2020 at 01:30, Jack Royal-Gordon wrote: >> I have read (and experienced by testing) that if, in a controller, you do a >> AR#find on a record id that does not exist, it throws an AR::RecordNotFound >> error which is trapped by the default error handling in controllers and >> results in a 404 status being returned by the controller. This happens with >> no special code added by the user. >> >> I have a test to verify this behavior, and it’s not working. >> >> it “fails on an invalid record ID” do >> get :show, id: -1 >> response.should_not be_success >> end >> >> >> This test produces: >> Failure/Error: get 'show', id: -1 >> ActiveRecord::RecordNotFound: >> Couldn't find Group with id=-1 >> >> >> What am I missing? > > -- > You received this message because you are subscribed to the Google Groups > "rspec" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/dejalu-217-e4a6438c-4d3c-49af-b56f-867b782b8ea9%40jonrowe.co.uk > > <https://groups.google.com/d/msgid/rspec/dejalu-217-e4a6438c-4d3c-49af-b56f-867b782b8ea9%40jonrowe.co.uk?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "rspec" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/4FF85616-529B-44B4-AAAB-30ACC42077E9%40pobox.com.
