Introduce have_reported_error matcher

[skatkov]

fixes #2827

rspec-rails is missing support for Rails ErrorReporter, this was introduced to rails in v7 and has been evolving ever since. With my client, we have moved to using ErrorReporter as a unified error reporting interface, so we can easily move from one error tracking software to another with minimal code changes. And we had a need to test this interface with rspec, so we implemented our own matcher to handle this.

I'm suggesting our internal implementation as is. This is probably not suitable as is for this gem, but I'd like to open discussion with this starting point.

Example usage

@example Checking for any error
  expect { Rails.error.report(StandardError.new) }.to have_reported_error

@example Checking for specific error class
  expect { Rails.error.report(MyError.new) }.to have_reported_error(MyError)

@example Checking for specific error instance with message
  expect { Rails.error.report(MyError.new("message")) }.to have_reported_error(MyError.new("message"))

@example Checking error attributes
  expect { Rails.error.report(StandardError.new, context: "test") }.to have_reported_error.with(context: "test")

@example Checking error message patterns
  expect { Rails.error.report(StandardError.new("test message")) }.to have_reported_error(/test/)

@example Negation
  expect { "safe code" }.not_to have_reported_error

[pirj]

Thank you!

[pirj]

This is unlikely to be needed, as ‘let’ will initialize a bew array each time, won’t it?

[pirj]

Can we do without this? Why is this mocking needed?

[pirj]

This suspiciously looks like passing an argument, and like the “value expectations” syntax.

Do you think a proper “this matcher doesn’t work with value expectations “ error will be shown to users on an attempt to use it mistakenly?

[pirj]

Is there a reason not to use the purposed matcher’s usage form like:

expect {
  expect { “no error reported” }.to have_reported_error
}.to fail_with(/failure message/)

[pirj]

This might be tested directly, by adding a spec with expect { } with this matcher.

[pirj]

Does it really pass when two errors were reported and we expect to have those two reported? Does the matcher fail if either of the errors was not reported?

[pirj]

I think this file is supposed to contain just the outline of the matchers defined here (and at a glance it’s rather incomplete). What do you think of keeping just one example of usage of this matcher? The rest will be taken into the same documentation from the feature file.

[pirj]

Is it a realistic example that a literal ‘Rails.error.report’ will be called? Or it’s rather some application logic that will bubble up the exception to eg a controller filter that would do that?

Would it be reasonable to give such a real-world-like example here, eg (borrowed from Rails guides) have_reported_error { process_service } ?

[pirj]

We usually provide an alias to accommodate both styles, like ‘send_email’ and ‘have_sent_email’. Would you be opposed to have ‘reports_error’ as an alias?