Embed the matcher into ExpectationNotMetError

[postmodern]

I think it would be useful to expose the expected and actual values in the ExpectationNotMetError exception. This would make it easier for other code bases to use expect() assertions, outside of RSpec/MiniTest.

[myronmarston]

I think it would be useful to expose the expected and actual values in the ExpectationNotMetError exception.

Seems like a good idea to me, provided we're careful about how we introduce this (see below).

This would make it easier for other code bases to use expect() assertions, outside of RSpec/MiniTest.

How does it make it easier for other code bases?

Anyhow, in the interest of preventing unintended breakage, I'd recommend a few things:

• ExpectationNotMetError should not require arguments for actual and expected. It should be possible to instantiate it with no arguments or one argument (the failure message) as it is now.
• expected and actual are an optional part of the matcher protocol so they are not always available. We need to handle this.
• It would be nice to be able to differentiate between "actual and expected not provided" and "actual and expected provided but were both nil". I'm not sure what the best way to do that is...maybe a has_actual_and_expected? predicate?

Want to take a stab at implementing this, @postmodern?

[myronmarston]

Actually, here's a better idea: let's add a matcher attribute to ExpectationNotMetError. The matcher includes additional details that might be useful (like description) and also will provide actual and expected if they are available at all. We could also think about adding a negative_expectation? (or similar) predicate that indicates if it was a positive or negative expectation.

[postmodern]

Whatever gives me the actual data structure that contains the information in the exception message. :+1:

[JonRowe]

Closing due to inactivity during the monorepo migration, but if someone wanted to revisit this they'd be welcome.