If you use aggregate failures here (either via running the test in an `aggregate_failures do … end` block or via tagging the example with the aggregate_failures metadata, your last example should give you one error that is the composite of the individual errors,
e.g. it should allow you to see any / all of the individual failures rather than just the first. You can also customise expectations by passing a message with them: e.g. expect(..).to matcher, “message” And you can always create fully custom composite matchers if you have more specific needs... Hope that helps Cheers Jon Rowe --------------------------- [email protected] jonrowe.co.uk On 10 July 2020 at 15:05, Jack Royal-Gordon wrote: > Consider the following call to a controller that you wish to test: > > get 'show', id: @event1.id > > Let’s say that you want to test that the code works as expected when the > Event ID is invalid (it could be that no such record exists or that the > record belongs to another user, etc.). So you want to test that it raises > ActiveRecord::RecordNotFound, and you also want to test that it redirects to > the right place or renders the right template, and you want to test that the > http status indicates failure. > > The obvious way to test for an exception is something like > > describe “failures” do > it “throws an exception” do > expect { get 'show', id: @event1.id }.to > raise_exception(ActiveRecord::RecordNotFound) > end > end > > But the obvious way to test for the side effects would be something like > > describe “failures” do > before(:each) do > get 'show', id: @event1.id > end > > it “signals failure” do > expect(response).to_not be_success > end > > it “renders the correct template” do > expect(response).to render_template(:index) > end > end > > or, the shorter but probably less desirable (because you would get the same > failure message for three different errors > > it “fails appropriately” do > get 'show', id: @event1.id > > expect(response).to_not be_success > > expect(response).to render_template(:index) > end > > > But neither of these forms mixes well with the exception checker example at > the top. In the interest of DRYing my example, I don’t want to repeat the > “get” command. So one thought on how to DRY it up would be the following: > > it “fails appropriately” do > expect { get 'show', id: @event1.id }.to > raise_error(ActiveRecord::RecordNotFound) > > expect(response).to_not be_success > > expect(response).to render_template(:index) > end > > > > but, as stated before, the failure messages are not very specific. So how can > I combine exception checking with side-effect checking with specific messages > for each test in a way that is DRY? > > Thanks for staying with this question all the way through! -- 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/dejalu-217-7e59b0ce-5ba2-4fe6-a3c6-fdc7b95db653%40jonrowe.co.uk.
