Bogus NPE if any() is used with primitive type arguments
See original GitHub issueMockito: 2.3.0, Java 8
When mocking a method invocation, if any() is used instead of anyInt() for exampe in the .when method call, a bogus NPE is thrown. There is quite a lot of explanations to the root cause of that, but it does not contain this hint.
I would expect either a compilation error or a more explanatory exception. Code: https://gist.github.com/axos88/163061ed82fcfdd9756d60d12eba8809
java.lang.NullPointerException
at xxx.WtfTest.testCaseNPE(WtfTest.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.mockito.internal.runners.SilentJUnitRunner.run(SilentJUnitRunner.java:39)
at org.mockito.internal.runners.StrictRunner.run(StrictRunner.java:39)
at org.mockito.junit.MockitoJUnitRunner.run(MockitoJUnitRunner.java:103)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
You cannot use argument matchers outside of verification or stubbing.
Examples of correct usage of argument matchers:
when(mock.get(anyInt())).thenReturn(null);
doThrow(new RuntimeException()).when(mock).someVoidMethod(anyObject());
verify(mock).someMethod(contains("foo"))
Also, this error might show up because you use argument matchers with methods that cannot be mocked.
Following methods *cannot* be stubbed/verified: final/private/equals()/hashCode().
Mocking methods declared on non-public parent classes is not supported.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:9 (5 by maintainers)
Top Results From Across the Web
Why do people still use primitive types in Java? - Stack Overflow
In Joshua Bloch's Effective Java, Item 5: "Avoid creating unnecessary objects", he posts the following code example:
Read more >ArgumentMatchers (Mockito 2.5.0 API) - Javadoc.io
If you are using argument matchers, all arguments have to be provided by matchers ... For primitive types use anyChar() family or isA(Class)...
Read more >JEP 401: Primitive Classes (Preview) - OpenJDK
Summary. Support new, developer-declared primitive types in Java. This is a preview language and VM feature.
Read more >Bug descriptions — spotbugs 4.7.3 documentation
A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. This method can be invoked as though it...
Read more >Check for null values in rules - IBM
Whether the object used in a rule is a parameter or a working memory ... Only values of Java primitive types such as...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi @bric3 , I believe this issue is appearing again, please see my below junit example:
When running this test I get the following output:
No mention of the above error or any real indication what is happening - I ended up using trial and error to determine what was going wrong.
Ah I see what’s happening, JUnit Runner performs an additional check after a test, and then report a matcher misuse. Because the matchers were not consumed byt the mock, the NPE is raised first.
Indeed we can mention that in the message. Thanks for insisting on this !