Skip to content

Conversation

@idoru
Copy link
Contributor

@idoru idoru commented May 8, 2015

Addresses part of the pain discussed in #326 by including type information with HaveReceived matcher failure messages.

This makes it more obvious when your test fails because your object expects a certain type but your test expectation unintentionally used the wrong type.

@briancroom
Copy link
Contributor

Thanks @idoru for getting this out there to keep the conversation going. I would prefer not to merge this as-is, because it seems that it decreases the signal-to-noise ratio in the majority of failure cases where type mismatches aren't the cause of the failure. I'm wondering if we can instead have a more specialized failure message that gets triggered when the expectation arguments don't match the types of the actual method.

I actually thought we had a behaviour like that in place already, but it doesn't seem to be working as I would have expected. I'll see if I can take a little time to investigate.

@idoru
Copy link
Contributor Author

idoru commented May 14, 2015

Yeah, I agree. This was easy enough to do, and I think you're right about the signal-to-noise ratio.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants