-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
MockitoJUnitRunner causes NPE when using @Mock on MockedStatic fields #1988
Comments
Just tried the tests with using MockitoRule and it's working as expected as well. |
…istort existing mock collectors that do not expect scoped mocks. Fixes #1988.
…istort existing mock collectors that do not expect scoped mocks. Fixes #1988.
…istort existing mock collectors that do not expect scoped mocks. Fixes #1988.
@raphw this issue still exists in 3.4.6. Was the PR supposed to fix all of this or only a part of it? The linked example above still causes NPE. This one: MockitoJUnitRunnerWithMockedStaticTest |
I was under the impression that I fixed it but I will take another look if it is not. I refactored your test and added it to the built but maybe I broke it in the process. |
I just ran the test with the latest Mocktio and it works as expected. Are you sure that you are running the right version? |
Yep, just doubled checked. It's using 3.4.6. Are you running my test class (without modification) or your refactored version of it? If you modified it, can you send me modified one and I'll double check it. |
Copy pasted it as it is i to the release/3.x branch. |
Okay, sorry for the confusion. When I was investigating this issue on July 25, I must have installed into locally and it got shoved into my local .m2 repo as 3.4.6 without the fix. Then when you fixed it and I updated the pom version to point to 3.4.6 it didn't redownload it because it was already in my local repo. I deleted it from my local .m2 repo and redownloaded it from maven-central. Everything is good now. Thanks! |
Perfect, Gradle does not work with snapshot versions, happened to me a few times, too. |
check that
Note that some configuration are impossible to mock via Mockito
(same as any question on stackoverflow.com)
Versions:
Example:
Problem:
The
MockitoJUnitRunner
is causing aNullPointerException
when the test class contains a@Mock
instance field with a type ofMockedStatic
. This exception only occurs for tests that are ran after a prior test fails. If all the tests pass, there are no issues.Stack Trace (Test 1):
Stack Trace (Test 2):
Investigation:
After some investigation, it appears the first test is failing twice (once in the test and once in the testFinished listener). This code:
mockito/src/main/java/org/mockito/internal/runners/DefaultInternalRunner.java
Lines 75 to 96 in 573bf0d
Line 81 is where it fails the second time. If we navigate down the call hierarchy, it appears it fails because the static mock has already been cleaned up so the framework doesn't think it's a mock and fails with a
NotAMockException
. Since it fails there, it doesn't set the listener to null which will in-turn result in the mocks not being initialized on the next test that's ran (hits line 51):mockito/src/main/java/org/mockito/internal/runners/DefaultInternalRunner.java
Lines 42 to 59 in 573bf0d
Since the mocks are not initialized for the second test, it ultimately causes the
NullPointerException
.It's also causing the remaining tests after the first test failure to bounce back and forth between
NullPointerException
andNotAMockException
. The reason for this appears to be because this failure object never gets reset after it's processed so it keeps restarting the chain of throwing the two exceptions back and forth.Also, I did include a sample test that manually opens and closes the mocks (doesn't use MockitoJUnitRunner) and everything is working as expected. Using the try-with-resource works fine as well.
I did investigate further and noticed something related to this might have been addressed in this PR. It only updated the findStubbings method to skip the static mocks, though. Was the AllInvocationsFinder.find(...) method intentional left out of that or just an oversight?
The text was updated successfully, but these errors were encountered: