Am I wrong in saying that the exception is to be expected in a Controller spec, and that if you want to test the status code you should do so in a Request spec?
When testing controllers, you’re not so much testing what Rails does with the result of the controller as what the controller is doing. And the controller is raising an exception. On the other hand, in a request spec, you’d be testing the result of the entire stack, which should be a 404, as Rails rescues ActiveRecord::RecordNotFound and sets the status code to 404. It seems that the majority of the testing world feels that Controller specs should be deprecated in favor of Request Specs for precisely the reason described above. Do you really care how the controller achieves it’s result, as long as it achieves the correct result? Personally, I like both types of tests because while the Request spec is an “Acceptance” test, the Controller spec may give you greater insight into what has gone wrong. > On Oct 7, 2021, at 1:54 AM, pirj...@gmail.com <pirjs...@gmail.com> wrote: > > https://guides.rubyonrails.org/action_controller_overview.html#the-default-500-and-404-templates > > <https://guides.rubyonrails.org/action_controller_overview.html#the-default-500-and-404-templates> > > > By default, in the production environment the application will render > > either a 404 or a 500 error message. In the development environment all > > unhandled exceptions are simply raised. > > > When running in the production environment, all > > ActiveRecord::RecordNotFound errors render the 404 error page. Unless you > > need a custom behavior you don't need to handle this. > > To me, it makes sense for you to set `show_exceptions` as you see fit for the > test environment, but doing so on `rspec-rails` level might be a surprising > for users that have `expect { response }.to raise_error(...)` expectations in > their specs. > > On Thursday, October 7, 2021 at 11:23:49 AM UTC+3 ma...@jonrowe.co.uk > <http://jonrowe.co.uk/> wrote: > Hi Byron > > Its because rspec-rails is a thin wrapper around rails own test helpers, so > we do what they do in terms of raising and rendering errors, it would be, in > our opinion, more confusing for us to have a different default from Rails. > > Cheers > Jon > > On Wed, 6 Oct 2021, at 2:07 PM, Byron Katz wrote: >> Hi all, >> >> On a basic negative test case, we want to ensure that when we PATCH to the >> wrong URL, we get a 404 error. The test looks like this (slightly modified >> to improve clarity): >> >> it 'fails if using a bad id' do >> patch our_endpoint(bad_id), params: form_params, as: :json >> expect(response).to have_http_status(:not_found) >> end >> when we run this, we get an exception, ActiveRecord::RecordNotFound >> >> It is thrown by #find not finding anything: >> >> def update >> post = Post.find(params[:id]) >> post.update(description: params[:description]) >> end >> My question is: if we're doing RSPec testing, shouldn't the default >> configuration be to return a 404 HTTP response instead of a Ruby exception? >> Is my understanding of the paradigm broken? All the examples showing RSpec >> testing API's work fine - return an HTTP response - for a success (200 >> response), but if it fails, it throws an exception (and doesn't return an >> HTTP response) >> >> By the way, I know how to correct this: as a workaround, we change the >> configuration in config > environments > test.rb as follows: >> >> # Raise exceptions instead of rendering exception templates. >> config.action_dispatch.show_exceptions = true >> or alternately, we can put that setting in the before method of the RSpec >> file, or in the rails_helper.rb under the spec directory, and again it works >> fine, but why wouldn't that be already set as default, given the paradigm >> I'm assuming of how RSpec is meant to work - that is, as much as possible >> with a outward-facing mentality? >> >> Thanks, >> >> Byron >> >> >> > >> -- >> 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 rspec+un...@googlegroups.com >> <applewebdata://C529FD7A-3D8F-4A26-AEF4-0B23D4680978>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rspec/e216b303-0061-4e16-bf17-2f36894b77can%40googlegroups.com >> >> <https://groups.google.com/d/msgid/rspec/e216b303-0061-4e16-bf17-2f36894b77can%40googlegroups.com?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 rspec+unsubscr...@googlegroups.com > <mailto:rspec+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/a4880d32-7dba-4e88-a65f-a25a2a8384a8n%40googlegroups.com > > <https://groups.google.com/d/msgid/rspec/a4880d32-7dba-4e88-a65f-a25a2a8384a8n%40googlegroups.com?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 rspec+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/E1D2C6DC-0F15-4D9C-8D64-B30F79606289%40pobox.com.
