You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
org.mockito.exceptions.misusing.PotentialStubbingProblem:
Strict stubbing argument mismatch. Please check:
- this invocation of 'match' method:
antPathMatcherMock.match(
"/ignored-path/**",
"/it-is/another-ignored-path"
);
-> at com.example.mockitomre.EndpointSieveConfig.lambda$errorPathEndpointSieve$0(EndpointSieveConfig.java:8)
- has following stubbing(s) with different arguments:
1. antPathMatcherMock.match(
"/*/another-ignored-path",
"/it-is/another-ignored-path"
);
-> at com.example.mockitomre.ErrorPathEndpointSieveTest.doesntAllowIgnoredPatterns(ErrorPathEndpointSieveTest.java:37)
Typically, stubbing argument mismatch indicates user mistake when writing tests.
Mockito fails early so that you can debug potential problem easily.
However, there are legit scenarios when this exception generates false negative signal:
- stubbing the same method multiple times using 'given().will()' or 'when().then()' API
Please use 'will().given()' or 'doReturn().when()' API for stubbing.
- stubbed method is intentionally invoked with different arguments by code under test
Please use default or 'silent' JUnit Rule (equivalent of Strictness.LENIENT).
For more information see javadoc for PotentialStubbingProblem class.
at org.springframework.util.AntPathMatcher.match(AntPathMatcher.java:195)
at com.example.mockitomre.EndpointSieveConfig.lambda$errorPathEndpointSieve$0(EndpointSieveConfig.java:8)
Is Mockito unhappy that I don't stub match("/*/another-ignored-path","/it-is/another-ignored-path") even though I call the method with those args? Nope. Replace the test method with this, it passes
// SNIPPET A// here, Mockito is fine with calling match("/ignored-path/**", "/it-is/another-ignored-path")@TestvoiddoesntAllowIgnoredPatterns() {
when(antPathMatcherMock.match("/ignored-path/**", "/ignored-path")).thenReturn(true);
when(antPathMatcherMock.match("/*/another-ignored-path", "/it-is/another-ignored-path")).thenReturn(true);
antPathMatcherMock.match("/ignored-path/**", "/ignored-path");
antPathMatcherMock.match("/*/another-ignored-path", "/it-is/another-ignored-path");
antPathMatcherMock.match("/ignored-path/**", "/it-is/another-ignored-path");
}
QUESTION №1. So what does Mockito want from me then?
You know what helps (beside ditching Mockito's extension altogether)? Making EndpointSieveConfig a nested class of ErrorPathEndpointSieveTest like so:
privatestaticList<Invocation> potentialArgMismatches(
Invocationinvocation, Collection<Stubbing> stubbings) {
List<Invocation> matchingStubbings = newLinkedList<>();
for (Stubbings : stubbings) {
if (UnusedStubbingReporting.shouldBeReported(s)
&& Objects.equals(
s.getInvocation().getMethod().getName(),
invocation.getMethod().getName())
// If stubbing and invocation are in the same source file we assume they are in// the test code,// and we don't flag it as mismatch:
&& !Objects.equals(
s.getInvocation().getLocation().getSourceFile(),
invocation.getLocation().getSourceFile())) {
matchingStubbings.add(s.getInvocation());
}
}
returnmatchingStubbings;
}
So now I realize that both "Snipppet A" and "Snippet B" didn't throw the PotentialStubbingProblem exception because the invocations were in the same source file as the stubbings
The (real) question. Why does it even matter?
"We assume it's test, we don't count". Can Mockito's team elaborate on this please? I fail to grasp the overall logic of it yet
P.S.: By the way, the StackOverflow user that helped me, discovered that this way of creating a strict mock
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Here's an MRE:
So here's the problem: once I run the test, I get
Is Mockito unhappy that I don't stub
match("/*/another-ignored-path","/it-is/another-ignored-path")
even though I call the method with those args? Nope. Replace the test method with this, it passesQUESTION №1. So what does Mockito want from me then?
You know what helps (beside ditching Mockito's extension altogether)? Making
EndpointSieveConfig
a nested class ofErrorPathEndpointSieveTest
like so:Now it passes!
Question №2. Why does moving the class solves the problem?
Thankfully, they helped me to find the culprit over there on StackOverflow. Here it is:
So now I realize that both "Snipppet A" and "Snippet B" didn't throw the
PotentialStubbingProblem
exception because the invocations were in the same source file as the stubbingsThe (real) question. Why does it even matter?
"We assume it's test, we don't count". Can Mockito's team elaborate on this please? I fail to grasp the overall logic of it yet
P.S.: By the way, the StackOverflow user that helped me, discovered that this way of creating a strict mock
doesn't work. You may want to look into it
Beta Was this translation helpful? Give feedback.
All reactions