Static methods mocking with Mockito

This is a placeholder ticket for enabling mocking static methods in Mockito. Example action items that are totally negotiable and can ran in parallel. We're looking for someone who can lead this effort.

• [x] Research + discuss whether it is a good idea to enable static methods mocking in Mockito. The theory is that it is useful for legacy code, which is most code in the world.
• [x] Research on how other mocking frameworks do that and whether it is considered useful feature for their users.
• [x] Design and present for discussion an API for static mocking (slightly relevant ticket: #643)
• [x] Work with @raphw / ByteBuddy to come up with hacky prototype (the hackier, the better!)
• [x] Mold the prototype with the API, remove enough rough edges so that the feature is good enough for incubating rollout
• [x] SHIP IT!

Hi guys,

I've taken a time for reviewing PowerMock code to find place where it use internal Mockito API. I'd like to discuss what could be done to avoid.

First think that I'd like to talk about it's MockMaker. PowerMock uses it custom MockMaker, which it past was used only for two things:

• cache a class create by CgLib
• return fake InternalMockHandler for static mocks.

The first case is no more actual, because ByteBuddy uses current context ClassLoader, so MockClassLoader is used. But the second case still actual. But investigation shows that returning fake InternalMockHandler is required only for one case right now.

Method org.mockito.internal.exceptions.Reporter.noMoreInteractionsWanted(Invocation undesired, List<VerificationAwareInvocation> invocations) tries to safelyGetMockName(undesired.getMock()). Finally, call comes to org.mockito.internal.util.MockUtilisMock(Object mock). It tries to get MockHandler for mock, but it mock is static and it's not a PowerMockMaker, then null is returned. I was surprised that having PowerMockMaker is required only for such thing. If speak, honestly, I don't have any idea, how it can be fixed on Mockito site. Maybe you have any thoughts?

The second point, it's a way how Mockito loads plugins. We had some discussion within #1006. Main point provided @podarsmarty (as for me main) that if there are two files org.mockito.plugins.MockMaker in class path, then order of loading plugins are unpredictable. Such undetermined behaviour could introduce some fluky bugs, when for example one plugin specified in project and other in dependency jar. And for example it works, but later author of dependency jar make refactoring and change package or something like this. As result other plugin is loaded by Mockito and tests start failed.

For PowerMock it is issue, because is has own MockMaker, which is required only if test runs with PowerMock. But, unfortunately, if PowerMock in class path it will be used always. If a developer wants to use mock-maker-inline to be able to mock final without PowerMock, then it was impossible until PowerMock 1.7.0, where I added ability to specify MockMaker to which PowerMockMaker delegates calls. As for me, it will be good to have ability to separate custom MockMaker and Mockito build-in MockMaker. So custom MockMaker could know which build-in MockMaker should be used to delegate call if its required.

This issue discusses:

• Mockito continuous delivery model (e.g. publishing every PR: wiki link)
• How to prevent prolonged Beta phases as it happened for v2

Hi,

Since version 2.24.0 I got the error "Mockito can only mock non-private & non-final classes.". Reverting back to Mockito 2.23.4 resolves the problem.

Stacktrace Underlying exception : java.lang.IllegalArgumentException: Could not create type at nl.tkp.ddw.pensioenaangifte.test.model.unittesten.AanleveringFilteringStepDefinitions.setup(AanleveringFilteringStepDefinitions.java:43) 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 cucumber.runtime.Utils$1.call(Utils.java:26) at cucumber.runtime.Timeout.timeout(Timeout.java:16) at cucumber.runtime.Utils.invoke(Utils.java:20) at cucumber.runtime.java.JavaHookDefinition.execute(JavaHookDefinition.java:60) at cucumber.runner.HookDefinitionMatch.runStep(HookDefinitionMatch.java:16) at cucumber.runner.TestStep.executeStep(TestStep.java:63) at cucumber.runner.TestStep.run(TestStep.java:49) at cucumber.runner.TestCase.run(TestCase.java:40) at cucumber.runner.Runner.runPickle(Runner.java:40) at cucumber.runtime.junit.PickleRunners$NoStepDescriptions.run(PickleRunners.java:146) at cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:68) at cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:23) 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 cucumber.runtime.junit.FeatureRunner.run(FeatureRunner.java:73) at cucumber.api.junit.Cucumber.runChild(Cucumber.java:124) at cucumber.api.junit.Cucumber.runChild(Cucumber.java:65) 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 cucumber.api.junit.Cucumber$1.evaluate(Cucumber.java:133) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118) 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157) at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IllegalArgumentException: Could not create type at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:154) at net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:365) at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:174) at net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:376) at org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:32) at org.mockito.internal.creation.bytebuddy.SubclassByteBuddyMockMaker.createMockType(SubclassByteBuddyMockMaker.java:71) at org.mockito.internal.creation.bytebuddy.SubclassByteBuddyMockMaker.createMock(SubclassByteBuddyMockMaker.java:42) at org.mockito.internal.creation.bytebuddy.ByteBuddyMockMaker.createMock(ByteBuddyMockMaker.java:25) at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:35) at org.mockito.internal.MockitoCore.mock(MockitoCore.java:62) at org.mockito.Mockito.mock(Mockito.java:1896) at org.mockito.internal.configuration.MockAnnotationProcessor.processAnnotationForMock(MockAnnotationProcessor.java:44) at org.mockito.internal.configuration.MockAnnotationProcessor.process(MockAnnotationProcessor.java:19) at org.mockito.internal.configuration.MockAnnotationProcessor.process(MockAnnotationProcessor.java:16) at org.mockito.internal.configuration.IndependentAnnotationEngine.createMockFor(IndependentAnnotationEngine.java:38) at org.mockito.internal.configuration.IndependentAnnotationEngine.process(IndependentAnnotationEngine.java:62) at org.mockito.internal.configuration.InjectingAnnotationEngine.processIndependentAnnotations(InjectingAnnotationEngine.java:49) at org.mockito.internal.configuration.InjectingAnnotationEngine.process(InjectingAnnotationEngine.java:41) at org.mockito.MockitoAnnotations.initMocks(MockitoAnnotations.java:69) ... 63 more Caused by: java.lang.NoSuchMethodError: net.bytebuddy.dynamic.loading.MultipleParentClassLoader$Builder.appendMostSpecific(Ljava/util/Collection;)Lnet/bytebuddy/dynamic/loading/MultipleParentClassLoader$Builder; at org.mockito.internal.creation.bytebuddy.SubclassBytecodeGenerator.mockClass(SubclassBytecodeGenerator.java:83) at org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator$1.call(TypeCachingBytecodeGenerator.java:37) at org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator$1.call(TypeCachingBytecodeGenerator.java:34) at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:152) ... 81 more

Versioninfo Java: 1.8 JVM vendor name: Oracle Corporation JVM vendor version: 25.191-b12 JVM name: Java HotSpot(TM) 64-Bit Server VM JVM version: 1.8.0_191-b12 JVM info: mixed mode OS name: Mac OS X OS version: 10.13.6 Mockito-core: 2.24.0

New Features in JUnit 5

The JUnit Jupiter extension model in JUnit 5 introduces support for constructor and method parameter resolution (i.e., dependency injection).

Specifically, third parties can implement the ParameterResolver extension API to inject dependencies, mocks, etc. into constructors and methods. In addition, the TestInstancePostProcessor extension API can be implemented to post-process a test instance (e.g., to perform field injection).

Status Quo

Mockito supports field injection for mocks via the @Mock annotation. In addition, #438 allows @Mock to be declared on parameters for constructors and methods which makes @Mock support an ideal candidate for both the TestInstancePostProcessor and ParameterResolver extension APIs in JUnit Jupiter. In fact, the JUnit Team has already developed a proof of concept: see the MockitoExtension in the junit5-mockito-extension sample project.

Deliverables

• [x] Introduce an official MockitoExtension for JUnit Jupiter to replace the proof of concept from the JUnit team.

Fixes #445

Discussion: https://groups.google.com/forum/#!topic/mockito/R1L1aG2RgBQ

First of all, thanks to the JUnit5-Team (@sbrannen) for that great API! The implementation was straight forward and the docu is top notch. Not comparable to a JUnitRule or Runner implementation. One can feel the hard work.

The here provided MockitoExtension allows to mock/spy/validate like the well known Mockito-JUnitRule/Runner. This is still "work in progress", feel free to comment.

Usage:

@ExtendWith(MockitoExtension.class)
class JUnit5Test {
 
  @Mock
  private Dependency mock ;

  @Test
  void checkMockCreation(){
    when(mock.foo()).thenReturn("Hello JUnit5");
    mock.foo();
    verify(mock).foo();
  }
}

We've upgraded from mockito-android:3.4.6 to mockito-android:3.5.0. I'm attempting to package up my instrumented tests by running the assembleAndroidTest gradle task. The task fails with the following errors:

/Users/<me>/.gradle/caches/transforms-2/files-2.1/fb7959dc5bfc8ebb26ad0660efa1929e/jetified-mockito-core-3.5.0.jar: D8: MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26)
/Users/<me>/.gradle/caches/transforms-2/files-2.1/4d4498fa5552ba637b5a9594a0871b80/jetified-objenesis-3.1.jar: D8: MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26)
/Users/<me>/.gradle/caches/transforms-2/files-2.1/4d4498fa5552ba637b5a9594a0871b80/jetified-objenesis-3.1.jar: D8: MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26)

and with root cause:

com.android.tools.r8.utils.b: Error: /Users/<me>/.gradle/caches/transforms-2/files-2.1/4d4498fa5552ba637b5a9594a0871b80/jetified-objenesis-3.1.jar:org/objenesis/instantiator/util/DefineClassHelper$Java8.class, java.lang.Class org.objenesis.instantiator.util.DefineClassHelper$Java8.defineClass(java.lang.String, byte[], int, int, java.lang.Class, java.lang.ClassLoader, java.security.ProtectionDomain), MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26)
        at com.android.tools.r8.utils.y0.a(:21)
        at com.android.tools.r8.utils.O.a(:51)
        ... 35 more

Please use this issue to review only the implementation. For API related discussions like why within() and not xy() please use ticket #472 Unify after() and timeout() !

Fixes: #472 Unify after() and timeout() Fixes: #417 Add new WithinRange VerificationMode Fixes: #345 Verification using After and ArgumentCaptor returns unexpected size of captured values list Fixes: #1037 Duplicate arguments captured with multithreaded method call Relates to: #91 Document Mockito.after() method

What

• This PR unifies the API of timeout() and after() into the new API within() that is accessible throu Mockito.within(..).
• This PR also includes an enhanced atLeast() API that allow to combine it with atMost() (see #417). Example: verify(mock, within(100,MILLISECONDS).atLeast(2).andAtMost(4)).simpleMethod();

How the behaviour differs from after/timeout

A within-verification always succeed or fail fast where applicable. Not all verification can fail or succeed fast. Eg. times(n) can only fail fast if more calls are detected but not succeed fast cause it needs to wait the full time if less calls than required where detected.

• Verification modes that check for a lower bound will succeed fast if enough calls were detected. Example:

mock.methodCall();
mock.methodCall();
mock.methodCall();
verify(mock, within(100,MILLISECONDS).atLeast(2)).methodCall()
//^ succeed immediatly, doesn't wait the full 100ms

• Verification modes that check for a upper bound will fail fast if more calls were detected. Example:

mock.methodCall();
mock.methodCall();
mock.methodCall();
verify(mock, within(100,MILLISECONDS).times(2))).methodCall()
//^ fails immediatly, doesn't wait the full 100ms

Compability

The within implementation is fully compatible cause it doesn't change the timeout or after API nor internal classes.

Implementation

Unlike after and timeout the within implementation doesn't poll for invocations in a loop but uses an queue based approach. When the verification starts all invocations that where made until now where placed in that queue. New invocations are added to the queue using an invocation listener. The queue will be polled and its invocations are passed to the verification strategy (e.g. never, atMost ,..) it decides if the verification condition is satified or the verification failed. This allows to fail or succeed fast.

Current state

The following verifications are working now:

• verify(atLeast(n))
• verify(atLeast(n).atMost(m))
• verfiy(atMost(n))
• verify(only())
• verify(times(n))
• verify(never())
• verify(within(duration,timeunit).atLeast(n))
• verify(within(duration,timeunit).atLeast(n).atMost(m))
• verfiy(within(duration,timeunit).atMost(n))
• verify(within(duration,timeunit).only())
• verify(within(duration,timeunit).times(n))
• verify(within(duration,timeunit).never())

Verifications InOrder are work in progress, thats why the tests fail.

Incompatible changes:

• [x] stop producing mockito-all #153
• [x] stop depending on hamcrest internally #154
• [x] use newer hamcrest #232
• [x] make the anyXxx and any(Xxx) matchers intuitive #134, #194
• ~~fix the site links~~
• [x] push cglib mockmaker to a separate jar #248
• [x] stop using ant for producing OSGi bundles. No more ant in the build #249
• [x] remove jars from source distribution #250
• ~~perhaps introduce is() matcher~~ #246
• ~~richer and smarter stubbing~~ #303
• ~~support java8 features for capturing arguments and matchers~~
• [x] make the JUnitRule and the runner verbose
• [x] ensure release notes can be neatly generated for the RC #582

Possibly compatible (and hence, could be released pre-2.0 if needed)

• [x] drop deprecated code
• [x] unincubate API
• ~~drop serialVersionUID~~

I had the need to be notified when ever a verification happens, this pr implements this.

To do anything useful with this notification the following data is important:

• The mock that we are verifying on.
• The verification mode we are using.
• And what method we wish to verify.

The one place where this data is collectable is in MockAwareVerificationMode.

What remains is to get the listeners there so we are able to notify them.

The tests I added try to follow those of the invocation listeners, however there might be more cases that are important that i'm unaware of.

Inline mocks allow for creating mocks of final types and final methods within any type. The inline mock engine also makes the mocking type invisible such that mock(Foo.class).getClass() == Foo.class. Exceptions need to be made for abstract types and for types with serialization requirements where final methods are still instrumented but where a subclass needs to be created nevertheless. There are however few limitations of the inline mock engine that do not apply for the subclass mock engine:

1. It is no longer possible to mock native methods which do not provide any byte code that can be manipulated.
2. Synchronized methods remain synchronized as the instrumentation API does not allow the changing of modifiers.

The final mock engine is activated just like any other custom mock engine by placing an indicator file into the root folder. To make this more convenient, an alias mechanism was added where the mock type name can be referenced by inline.

It seems like there is a gap in tests: the tests get mock maker instance (from environment setting) but not the member accessor it supposed to be used with. As such, the tests used reflection, not module accessor, all the time (see please https://github.com/mockito/mockito/pull/2834#issuecomment-1374876590).

check that

• [ ] The mockito message in the stacktrace have useful information, but it didn't help
• [ ] The problematic code (if that's possible) is copied here; Note that some configuration are impossible to mock via Mockito
• [ ] Provide versions (mockito / jdk / os / any other relevant information)
• [ ] Provide a Short, Self Contained, Correct (Compilable), Example of the issue (same as any question on stackoverflow.com)
• [ ] Read the contributing guide

@TimvdLippe I could take it if you don't mind, thank you

I'm working on validating the software supply chain for another project and I haven't been able to find a definitive statement about the package signing key used by the Mockito project. As a result, we're currently using rather an old version.

It looks like the packages in Maven Central are signed with key 0x689CBE64F4BC997F, which claims it belongs to @mockitoguy ... but there are no cross-signatures so just knowing the key doesn't provide any assurance.

A fairly common practice is for projects to publish a KEYS file containing the public keys used by the project, either in the repository or on the web site. Is it possible that the Mockito project could do this?

My apologies in advance if this information is already published and I just failed to find it.

In my project, there are a number of calls that are made to initialise new instances of classes. In my tests that make use of Mockito, the ability to mock the construction of these classes is very useful as it prevents behaviour within the target class leaking into the unit tests for the class under construction.

The main issue I have currently is that there does not seem to be a simple way to verify that the constructor is called correctly for these types. The current workaround I am employing is ensuring internal classes have private constructors, and then get initialised via static methods, but this feels like a bit of a poor solution.

Ideally, I'd like to be able to write something like this:

class ClassUnderTest {
  public void doSomething() {
    // ...
    var dataClass = new SomeDataClass(123, "foobar");
    // ...
  }
}

class SomeDataClass {
  public SomeDataClass(int arg1, String arg2) {}

  public void doSomethingElse() {}
}

class SomeTest {
  @Test
  void testTheDataClassIsInitialisedCorrectly() {
    try (var mock = mockConstruction(SomeDataClass.class)) {
      // Given
      var underTest = new ClassUnderTest();
      
      // When
      underTest.doSomething();

      // Then
      mock.verify(() -> new SomeDataClass(123, "foobar"));
      verify(mock.constructed().get(0)).doSomethingElse();
    }
  }
}

Would this be something that is possible for potential inclusion? I had a quick look to see if I could work out how something like this could be implemented, but got stuck with an issue regarding the mock context being of the wrong type, and I didn't want to delve too deep into trying to implement something like this if there is any technical reason that this could not be supported.

This may also be useful for mocking interactions with record types in the future, as well. In addition, this could be useful to test builder types, such as the following:

public final class User {
  private final int userId;
  private final String userName;

  private User(Builder builder) {
    userId = requireNonNull(builder.userId);
    userName = requireNonNull(builder.userName);
  }
  
  public int getUserId() { return userId; }
  public String getUserName() { return userName; }

  public static Builder builder() {
    return new Builder();
  }

  public static final class Builder {
    private Integer userId;
    private String userName;

    private Builder() {
      userId = null;
      userName = null;
    }

    public Builder userId(int userId) {
      this.userId = userId;
      return this;
    }

    public Builder userName(String userName) {
      this.userName = userName;
      return this;
    }

    public User build() {
      return new User(this);
    }
  }
}

I have tried to see if I can see any existing issues regarding this, but I don't seem to be able to see anything. If I have made this in the wrong place or missed an existing issue, then I apologise in advance!

Thanks!

Include some context in InOrder examples and add an example that uses a static mock as well.

I spent a while being unable to work out how to integrate InOrder with static mocks before realising the example of how to do this is currently encoded in a specific overload of a specific method within InOrder that I had missed as I was not using it.

Checklist

• [x] Read the contributing guide
• [x] PR should be motivated, i.e. what does it fix, why, and if relevant how
• [x] If possible / relevant include an example in the description, that could help all readers including project members to get a better picture of the change
• [x] Avoid other runtime dependencies
• [x] Meaningful commit history ; intention is important please rebase your commit history so that each commit is meaningful and help the people that will explore a change in 2 years
• [x] The pull request follows coding style

Since JUnit 5 it is supported to inject dependencies as parameters in test class constructor. The @Mock annotation is allowed on parameters as well. Unfortunately, unnecessary stubbing detection does not work in the scenario of injecting mocks this way.

Assume there is a class MyClass wich should call a method from its dependency MyChecker .

class MyClass {

    boolean doSomeThing() {
        // should but does not call myChecker
        return true;
    }
}

class MyChecker {

    boolean checkSomeThing() {
        return false;
    }
}

The test should ensure that the dependency of the test subject is called in the tested method. The expected behavior would be, that a UnnecessaryStubbingException occurs, while strict stubbing is activated as default by using the MockitoExtension with JUnit 5. Unexpectedly, the unnecessary stubbing detection does not work in the case that the mock is injected through the test class constructor.

import static org.mockito.Mockito.when;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
class MyClassConstructorInjectionTest {

    private final MyChecker myCheckerMock;
    private final MyClass testSubject;

    MyClassConstructorInjectionTest(@Mock MyChecker myCheckerMock) {
        this.myCheckerMock = myCheckerMock;

        testSubject = new MyClass();
    }

    @Test
    void returnsResultFromCheck() {
        when(myCheckerMock.checkSomeThing()).thenReturn(true);

        Assertions.assertTrue(testSubject.doSomeThing());
    }
}

mockito-junit-jupiter: 4.10 version: junit_jupiter: 5.9.0 ORACLE JDK 11.0.15

Consider classes A and B

public class A {
    String call() {
        return null;
    }
}

public class B extends A {
}

And class C, contructor of which uses inctances of both A and B

public class C {
    private final A a;
    private final B b;

    C(A a, B b) {
        this.a = a;
        this.b = b;
    }

    public void callFields() {
        System.out.println("A " + a.call());
        System.out.println("B " + b.call());
    }
}

In that case following test does not behave consistently

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import static org.mockito.Mockito.when;

@ExtendWith(MockitoExtension.class)
class MockitoTest {
    @Mock
    A a;
    @Mock
    B b;
    @InjectMocks
    C c;

    @Test
    void test() {
        when(a.call()).thenReturn("A");
        when(b.call()).thenReturn("B");
        c.callFields();
    }
}

org.junit.jupiter:junit-jupiter:5.9.1 org.mockito:mockito-junit-jupiter:4.8.1 openjdk version "17.0.3" 2022-04-19 LTS