dhamini-poornachandra / mockito

Automatically exported from code.google.com/p/mockito
0 stars 0 forks source link

use describeMismatch for verification errors #409

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Hamcrest matchers can provide a more detailed mismatch description, which is 
(in combination with `argThat`) especially helpful when you have a complex 
condition, or the argument does not provide a proper toString() implementation.

Example:

Foo foo = mock(Foo.class);
foo.setInt(12);
verify(foo).setInt(argThat(isPrime()));

Actual output:

Argument(s) are different! Wanted:
foo.setInt(prime);
-> at Test.test(Test.java:11)
Actual invocation has different arguments:
foo.setInt(12)
-> at Test.test(Test.java:10)

Expected output:

Argument(s) are different! Wanted:
foo.setInt(prime);
-> at Test.test(Test.java:11)
Actual invocation has different arguments:
foo.setInt(12: multiple of 2, 3, 4, ...)
-> at Test.test(Test.java:10)

A prototype for a fix can be found here: 
http://code.google.com/r/derariii-mockito-descrmismatch/source/checkout
It calls `describeMismatch` via reflection to ensure compatibility with older 
hamcrest versions.

Original issue reported on code.google.com by derar...@gmail.com on 4 Jan 2013 at 12:53

GoogleCodeExporter commented 8 years ago
Note: a test case for the new behavior can be found at the bottom of 
http://code.google.com/r/derariii-mockito-descrmismatch/source/browse/test/org/m
ockito/internal/matchers/MatchersPrinterTest.java

Original comment by derar...@gmail.com on 4 Jan 2013 at 12:56

GoogleCodeExporter commented 8 years ago
Hi, thx

It might take some time but we will look at it :)

Original comment by brice.du...@gmail.com on 8 Jan 2013 at 4:43

GoogleCodeExporter commented 8 years ago
My custom matcher suffers the same diagnosis problem.
XStreamMatcher that matches iff 
XStream.toXML(actual).equals(XStream.toXML(wanted))

BTW: Best would be, if I could use the library instead of writing my own 
matcher.
The missed method could be located in Matchers and work similar as 
Matchers.refEq.

@Test
public void someTest() {
    someAction();
    verify(mock).someCall(xstreamEq(expectedParam));
}

Original comment by frank.ne...@gmail.com on 10 Apr 2013 at 5:05

GoogleCodeExporter commented 8 years ago

Original comment by brice.du...@gmail.com on 29 Apr 2013 at 4:14

GoogleCodeExporter commented 8 years ago
Any progress on this? I would like to be able to use 
verify(mock).someCall(argThat( ... )) in conjunction with my own 
TypeSafeDiagnosingMatchers. Thanks!

Original comment by jplic...@gmail.com on 4 Oct 2013 at 4:31

GoogleCodeExporter commented 8 years ago
I;m affected by this issue. Any plans on implementing this feature?

Original comment by tomasz.k...@gmail.com on 10 Oct 2014 at 8:57

GoogleCodeExporter commented 8 years ago
For what it's worth: I plan to fix this soonish ... 

Original comment by mz.li...@gmail.com on 10 Oct 2014 at 9:52

GoogleCodeExporter commented 8 years ago
Hey guys,

I encourage to contribute - create a pull request in github and it looks good 
we'll merge and release shortly :)

Original comment by dorota.f...@gmail.com on 10 Oct 2014 at 6:30

GoogleCodeExporter commented 8 years ago
For my part (today), I've taken derariii's changes and rebased on master at 
https://github.com/mockito/mockito/compare/master...skestle:derariii/409?expand=
1

Was a bit sad that nobody's pushed this. Does anybody use mockito with 
hamcrest? Seems rather difficult to me.

Original comment by stephen....@gmail.com on 10 Jun 2015 at 8:18

GoogleCodeExporter commented 8 years ago
I also have a PR in since March: https://github.com/mockito/mockito/pull/167 

I asked about the plans to include it, no responses yet.

Original comment by mz.li...@gmail.com on 10 Jun 2015 at 8:22