Adds output of matchers to potential mismatch; Fixes #2468 - #3760
Conversation
TimvdLippe
left a comment
There was a problem hiding this comment.
Nice work, excited to see this land! Can we also add a testcase that uses the argThat as mentioned in #2468 That way we know how we serialize argThat matchers and if that is human readable. Thanks!
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3760 +/- ##
============================================
+ Coverage 86.45% 86.46% +0.01%
Complexity 2988 2988
============================================
Files 341 341
Lines 9041 9041
Branches 1113 1113
============================================
+ Hits 7816 7817 +1
+ Misses 943 942 -1
Partials 282 282 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
6e5039d added. Output is definitely human readable, though making it more specific feels like it would need an |
TimvdLippe
left a comment
There was a problem hiding this comment.
Thanks for contributing! Would be good to indeed add an additional method so that argThat matchers can optionally add a description as well.
Checklist
including project members to get a better picture of the change
commit is meaningful and help the people that will explore a change in 2 years
./gradlew spotlessApplyfor auto-formatting)Fixes #<issue number>in the description if relevantFixes #<issue number>if relevantAn example of what this looked like before, as described in #2468

This brings matchers more in line with the kind of output
verifyoutputs for similar operations. It does also add what the stub is configured to return, such asstubbed with: [Returns: 40], which im less opinionated about. I could see it being useful though, and it would be more effort to remove it, so i left it until someone requests otherwise.If im missing some part of the process or this needs further work, more than happy to hear about it.