As per latest documentation of version 4.2.0 it looks like mockito community has come up with mockito-inline for some experimental features like mocking final classes and methods, mocking static methods etc. So once they get feedback from community they will merge those changes in mockito-core and abolished mockito-inline. Eventually it will be mockito-core only.
https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#mockito-inline https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#39
Answer from Prakash Boda on Stack OverflowAs per latest documentation of version 4.2.0 it looks like mockito community has come up with mockito-inline for some experimental features like mocking final classes and methods, mocking static methods etc. So once they get feedback from community they will merge those changes in mockito-core and abolished mockito-inline. Eventually it will be mockito-core only.
https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#mockito-inline https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#39
As of Mockito 5.0.0, mockito-inline is the default mock maker:
This mockmaker [mockito-inline] creates mocks manipulating bytecode equivalent within the original class such that its method implementations hook into the normal Mockito machinery. As a comparison, the subclass mockmaker generates "real" subclasses for mocks, to mimic the same behavior. While the approaches are similar, the inline mockmaker avoids certain restrictions that the JDK imposes. For example, it does not violate module boundaries (introduced in JDK 9, but more heavily used in JDK 17) and avoids the leaking of the creation of the subclass.
mockito-inline was a separate, configuration-free artifact. (If you wanted to use inline mock making with mockito-core, you had to configure the MockMaker extension file.) However, since Mockito 5.3.0, mockito-inline is no longer published!
If you want to (or have to) use subclass mock making after 5.0.0, there is again a separate, configuration free artifact: mockito-subclass.
There are legitimate remaining use cases for the subclass mockmaker. For example, on the Graal VM's native image, the inline mockmaker will not work and the subclass mockmaker is the appropriate choice. Additionally, if you would like to avoid mocking final classes, using the subclass mockmaker is a possibibility. Note however that if you solely want to use the subclass mockmaker to avoid mocking final, you will run into the above mentioned issues on JDK 17+. We want to leave this choice up to our users, which is why we will keep on supporting the subclass mockmaker.
quarkus-junit5-mockito is NOT deprecated.
What is deprecated is the io.quarkus.test.junit.mockito.InjectMock annotation, nothing else.
The replacement is the io.quarkus.test.InjectMock annotation, together with io.quarkus.test.junit.mockito.InjectMock if you need the extra options.
I found a way. I'm not using something deprecated.
Mocking with QuarkusMock
My example:
ExtensionsService customMock = new ExtensionsService() {
@Override
public JsonObject getForbiddenNumbers() {
return new JsonObject("{\"forbiddenNumbers\":[5,7,23]}");
}
};
QuarkusMock.installMockForType(customMock, ExtensionsService.class, RestClient.LITERAL);
In this example ExtensionsService is the rest client.
For more information: Quarkus documentation
Finally fixed, both in command line and IDE (IntelliJ IDEA). There are two different warnings, so the fix comes in two parts, you can try each argument on its own to see the effect:
Copy<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>
-javaagent:${settings.localRepository}/org/mockito/mockito-core/${mockito.version}/mockito-core-${mockito.version}.jar
-Xshare:off
</argLine>
</configuration>
</plugin>
No need for -XX:+EnabledDynamicAgentLoading or maven-dependency-plugin.
All the credit goes to this and this answers.
Also, take a look at this to understand why some configuration might only work for the build tool or the IDE. So you should use a neutral configuration, otherwise you will need a different configuration for each.
For gradle projects you can try this. Tested on Intellij only.
Copytest {
jvmArgs "-javaagent:${configurations.testRuntimeClasspath.find { it.name.contains('mockito-core') }}", '-Xshare:off'
...
}