Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected Argument error feedback #15

Open
doubt72 opened this issue Jan 14, 2016 · 3 comments
Open

Unexpected Argument error feedback #15

doubt72 opened this issue Jan 14, 2016 · 3 comments

Comments

@doubt72
Copy link

doubt72 commented Jan 14, 2016

It would be very helpful if the mocks (when raising an unexpected argument error) could also display what they are expecting for a particular function call.

Especially when dealing with complex records being passed, it can often be somewhat difficult to figure out what the mismatch is or what's causing it, requiring extra debugging to figure out what's out of alignment. Diffs would also be nice bonus feature.

@MattVonVielen
Copy link
Owner

Rspec-Style diffs would be superb, but non-trivial to implement. However, I just hacked together a quick proof of concept that does the following; is this an acceptable short-term improvement?

**error:{unexpected_arguments,["m:f/2","parameter 2 expected 2 but got a"]}

The wrinkle in this whole problem is in cases where one test defines multiple different expectations for the same function (with different expected arguments). It's relatively rare but it does crop up from time to time. In that scenario, I can't think of any way to sensibly represent any form of diff without spewing an unhelpful wall of text - so until a better idea arises, as a special case, in those scenarios the current error would continue to be raised.

Thoughts @doubt72?

@MattVonVielen
Copy link
Owner

Also, the implementation of what I just mentioned could be extended pretty easily to recursively descend and compare non-scalar (list, tuple) arguments as long as expected and actual values are the same type. There would be no way for me to tell you the named field of a record which is different, since records are compile-time sugar for tuples, but I could perhaps point you to something like "parameter 3, {element 2, {element 8 expected passed got failed}}"

MattVonVielen added a commit that referenced this issue Jan 21, 2016
Compares and reports on different arguments at top level.
Could be nice in future to recursively descend non-scalar types to
find which sub-elements differ.
@doubt72
Copy link
Author

doubt72 commented Jan 21, 2016

Yeah, I'm doing a fair bit of multiple expectations (worse than that, changing expectations, but I'll ping you about that offline -- this may require me to just redesign my tests). I suppose in that case the diffs are less useful anyway, since I (probably) know which one I wanted to match anyway, and the computer doesn't. I don't know if it's possible to do something in that case like "expected \n ---OR--- \n \n --- BUT GOT --- \n "

But any improvement helps, so would of course be acceptable. :) It's better than what I'm doing which is dumping out the args I put in the mocks where I make them when I do get something I didn't expect.

MattVonVielen added a commit that referenced this issue Jan 22, 2016
…ncements

Experimental first pass at ameliorating #15
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

No branches or pull requests

2 participants