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
Unused stubbings are not reported when filters are used #3077
Comments
I've held off on providing a reproducible example as I hope the description is clear enough; can give it a shot if more detail is required, though. |
C0urante
added a commit
to C0urante/mockito
that referenced
this issue
Aug 4, 2023
C0urante
added a commit
to C0urante/mockito
that referenced
this issue
Aug 4, 2023
8 tasks
Added a unit test case to #3078 that gives a decent picture of what this describes, but without some of the outer context (e.g., Gradle and JUnit exclusion categories) that helps demonstrate the impact of the current behavior. |
C0urante
added a commit
to C0urante/mockito
that referenced
this issue
Aug 4, 2023
C0urante
added a commit
to C0urante/mockito
that referenced
this issue
Aug 6, 2023
TimvdLippe
pushed a commit
that referenced
this issue
Aug 8, 2023
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unused stubbings are not reported when a filter is used during the test run. This is documented clearly in the StrictRunner class:
Only reporting unused stubbings when all tests are run is reasonable. However, the logic for detecting this case is a little too coarse-grained, since even no-op filters end up disabling the reporting of unused stubbings. This can be troublesome when, for example, JUnit categories are used to distinguish between unit and integration tests.
It'd be nice if we could detect when filters actually prevent one or more tests from being run, and only skip reporting unused stubbings in those cases.
Created based off of gradle/gradle#10694, specifically this comment.
This affects a project currently using Mockito version 4.11.0, but I've just verified that it also affects version 5.2.0.
The text was updated successfully, but these errors were encountered: