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
Add matchers for incompatible type matchers #1832
Conversation
We discovered that users run into issues with using the wrong Mockito matcher for arguments. Examples include `any(Integer.class)` instead of `anyInt()` and `anyInt()` instead of `anyFloat()`. Users then run into cryptic run-time errors that are difficult to understand. These ErrorProne checkers make these a compile warning, to warn the user before hand. They also provide the appropriate fixes that can be directly applied.
263f7c4
to
4b3cedf
Compare
Codecov Report
@@ Coverage Diff @@
## release/3.x #1832 +/- ##
=================================================
- Coverage 86.71% 86.64% -0.08%
- Complexity 2492 2507 +15
=================================================
Files 311 314 +3
Lines 6551 6613 +62
Branches 822 829 +7
=================================================
+ Hits 5681 5730 +49
- Misses 674 682 +8
- Partials 196 201 +5
Continue to review full report at Codecov.
|
@TimvdLippe Sample:
|
@ChristianSchwarz That would lead to a lot of confusing code. E.g. half of the matchers would be For now, we can keep this checker and we can revisit your suggestion in the future. Do you mind filing a bug? |
I am merging this for now, as it upstreams a checker that prevents real issues on runtime. We can change the Mockito API, but I would rather prevent users from running into runtime exceptions when we can. |
We discovered that users run into issues with using the wrong Mockito matcher for arguments. Examples include `any(Integer.class)` instead of `anyInt()` and `anyInt()` instead of `anyFloat()`. Users then run into cryptic run-time errors that are difficult to understand. These ErrorProne checkers make these a compile warning, to warn the user before hand. They also provide the appropriate fixes that can be directly applied.
We discovered that users run into issues with using the wrong Mockito
matcher for arguments. Examples include
any(Integer.class)
instead ofanyInt()
andanyInt()
instead ofanyFloat()
. Users then run intocryptic run-time errors that are difficult to understand.
These ErrorProne checkers make these a compile warning, to warn the user
before hand. They also provide the appropriate fixes that can be
directly applied.