Improve error messages from unfulfilled expectations

[MarkKoester]

Currently, the error messages that are generated from unfulfilled expectations are cryptic and hard to debug. I almost always have to step through my failing test with a debugger to figure out what the issue is.

Right now the main issues I have are that there's a lot of noise in the error messages and it's hard to parse exactly why an expectation didn't match. Improving these error messages would definitely make this library more user-friendly.

[rollbear]

OK, can you give some hints about information you are missing that you'd like to see, or example of information that is misleading that can be improved?

[MarkKoester]

Here's one example:

First, there's a lot of unnecessary information in this message. I feel like most of text here isn't all that relevant when debugging besides "No match for call to receiveAck...", so most of it is noise besides a portion of the middle line.

Second, it's hard to parse exactly what caused the error from the message. I can tell that receiveAck was called when it shouldn't have been, but that's basically all I know. I still have to do some extra work to answer these questions:

• Did the test case expect receiveAck to never be called and it was called once? (This was the actual issue)
• Did the test case expect a call to receiveAck but the argument didn't match?
• Did the test case expect receiveAck to be called 3 times and it was actually called 4 times?

Basically, I think it would be awesome if the error messages were less noisy and more targeted, and clearly highlighted the difference between the expected behavior and the actual behavior.

Thanks for taking the time to respond to this.