Most popular Mocking framework for unit tests written in Java

Overview
Mockito

Most popular mocking framework for Java

CI Coverage Status MIT License

Release Notes Maven Central Javadoc

Current version is 3.x

Still on Mockito 1.x? See what's new in Mockito 2! Mockito 3 does not introduce any breaking API changes, but now requires Java 8 over Java 6 for Mockito 2.

Mockito for enterprise

Available as part of the Tidelift Subscription

The maintainers of org.mockito:mockito-core and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use. Learn more.

Development

Mockito publishes every change as a -SNAPSHOT version to a public Sonatype repository. Roughly once a month, we publish a new minor or patch version to Maven Central. For release automation we use Shipkit library (http://shipkit.org), Gradle Nexus Publish Plugin. Fully automated releases are awesome, and you should do that for your libraries, too! See the latest release notes and latest documentation. Docs in javadoc.io are available 24h after release. Read also about semantic versioning in Mockito.

Older 1.x and 2.x releases are available in Central Repository and javadoc.io (documentation).

More information

All you want to know about Mockito is hosted at The Mockito Site which is Open Source and likes pull requests, too.

Want to contribute? Take a look at the Contributing Guide.

Enjoy Mockito!

Need help?

How to develop Mockito?

To build locally:

 ./gradlew build

To develop in IntelliJ IDEA you can use built-in Gradle import wizard in IDEA. Alternatively generate the importable IDEA metadata files using:

 ./gradlew idea

Then, open the generated *.ipr file in IDEA.

How to release new version?

  1. Every change on the main development branch is released as -SNAPSHOT version to Sonatype snapshot repo at https://s01.oss.sonatype.org/content/repositories/snapshots/org/mockito/mockito-core.
  2. In order to release a non-snapshot version to Maven Central push an annotated tag, for example:
git tag -a -m "Release 3.4.5" v3.4.5
git push origin v3.4.5
  1. At the moment, you may not create releases from GitHub Web UI. Doing so will make the CI build fail because the CI creates the changelog and posts to GitHub releases. We'll support this in the future.
Comments
  • Enable mocking static methods in Mockito

    Enable mocking static methods in Mockito

    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!
    android please contribute feedback-needed 
    opened by mockitoguy 106
  • PowerMock and MockMaker: API change request.

    PowerMock and MockMaker: API change request.

    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.

    opened by thekingn0thing 99
  • Mockito continuous delivery model

    Mockito continuous delivery model

    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
    opened by mockitoguy 82
  • Unexpected error (Mockito can only mock non-private & non-final classes.) in version 2.24.0

    Unexpected error (Mockito can only mock non-private & non-final classes.) in version 2.24.0

    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

    opened by frankvanderkuur 81
  • Introduce MockitoExtension for JUnit Jupiter (a.k.a. JUnit 5)

    Introduce MockitoExtension for JUnit Jupiter (a.k.a. JUnit 5)

    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.
    enhancement new feature please contribute junit5 
    opened by sbrannen 64
  • MockitoExtension for JUnit5

    MockitoExtension for JUnit5

    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();
      }
    }
    
    junit5 
    opened by ChristianSchwarz 63
  • Android instrumentation test packaging fails for mockito-android 3.5.0 with minSdk < 26

    Android instrumentation test packaging fails for mockito-android 3.5.0 with minSdk < 26

    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
    
    android please contribute 
    opened by DeuceTheCoder 54
  • [WIP] Unification of timeout(..) and after(..) API aka within()

    [WIP] Unification of timeout(..) and after(..) API aka within()


    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.

    in progress 
    opened by ChristianSchwarz 47
  • Release Mockito 2.0

    Release Mockito 2.0

    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~~
    epic 
    opened by mockitoguy 46
  • Verification listeners

    Verification listeners

    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.

    enhancement 
    opened by LiamClark 44
  • Added InlineByteBuddyMockMaker which uses the instrumentation API for redefining classes and inlining the mocking logic.

    Added InlineByteBuddyMockMaker which uses the instrumentation API for redefining classes and inlining the mocking logic.

    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.

    new feature final-class-or-methods 
    opened by raphw 44
  • Make sure the tests use mock maker with intended member accessor

    Make sure the tests use mock maker with intended member accessor

    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

    opened by reta 0
  • Please publish package signing keys

    Please publish package signing keys

    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.

    opened by iay 1
  • Allow verification of constructor calls

    Allow verification of constructor calls

    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!

    opened by ascopes 0
  • Improve examples for InOrder

    Improve examples for InOrder

    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
    opened by ascopes 1
  • No unnecessary stubbing detection when mocks are injected through constructor

    No unnecessary stubbing detection when mocks are injected through constructor

    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

    opened by dev-uhlenbrock 1
  • Inconsistent behaviour of @InjectMocks annotation

    Inconsistent behaviour of @InjectMocks annotation

    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();
        }
    }
    

    image image

    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

    opened by el-hopaness-romtic 0
Releases(v4.11.0)
  • v4.11.0(Dec 28, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.11.0

    • 2022-12-28 - 1 commit(s) by Andy Coates
    • Improve vararg handling: approach 2 (#2807)
    • Mocking varargs method with any(String[].class) doesn't work as expected (#2796)
    • (Argument)Matchers regression from 1.10.19 to 2.18.3 for varargs (#1498)
    • Cannot verify varargs parameter as an array (#1222)
    • ArgumentCaptor can't capture varargs-arrays (#584)
    • Verification of an empty varargs call fails when isNotNull() is used (#567)
    Source code(tar.gz)
    Source code(zip)
  • v4.10.0(Dec 14, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.10.0

    • 2022-12-14 - 13 commit(s) by Andrei Solntsev, Andriy Redko, Andy Coates, Christopher Lambert, Marcono1234, Vladimir Glinskikh, dependabot[bot]
    • Add new artifact mockito-subclass (to use mock-maker-subclass MockMaker) (#2821)
    • Bump gradle from 7.5.1 to 7.6 (#2817)
    • Fix incorrect Javadoc inline tag for MockitoJUnitRunner (#2816)
    • Bump shipkit-auto-version from 1.2.1 to 1.2.2 (#2811)
    • Bump com.github.ben-manes.versions from 0.42.0 to 0.44.0 (#2810)
    • Bump kotlinVersion from 1.7.21 to 1.7.22 (#2809)
    • Bump junit from 1.1.3 to 1.1.4 (#2806)
    • Simplify MatcherApplicationStrategy (#2803)
    • Bump kotlinVersion from 1.7.10 to 1.7.21 (#2801)
    • Bump espresso-core from 3.4.0 to 3.5.0 (#2800)
    • Bump versions.bytebuddy from 1.12.16 to 1.12.19 (#2799)
    • Upgrade errorprone from 2.14.0 to 2.16 (#2794)
    • automatically detect class to mock (#2779)
    Source code(tar.gz)
    Source code(zip)
  • v4.9.0(Nov 14, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.9.0

    • 2022-11-14 - 6 commit(s) by Andrei Solntsev, Rafael Winterhalter, Rick Ossendrijver, dependabot[bot]
    • Upgrade objenesis 3.2 -> 3.3 (#2784)
    • Upgrade objenesis 3.2 -> 3.3 (#2783)
    • Avoids clearing stale weak entries from critical code segments. (#2780)
    • bump gradle from 7.3.1 to 7.5.1 (#2776)
    • Bump gradle/wrapper-validation-action from 1.0.4 to 1.0.5 (#2775)
    • Bump gradle-errorprone-plugin from 2.0.2 to 3.0.1 (#2770)
    • Bump junit-platform-launcher from 1.9.0 to 1.9.1 (#2768)
    Source code(tar.gz)
    Source code(zip)
  • v4.8.1(Oct 17, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.8.1

    • 2022-10-17 - 6 commit(s) by andrepaschoal, dependabot[bot]
    • Possible fix #2765: Add task to download package-list file from java as element-list (#2766)
    • JavaDoc warning is blocking all pull requests (#2765)
    • Bump versions.junitJupiter from 5.9.0 to 5.9.1 (#2758)
    • Bump groovy from 3.0.12 to 3.0.13 (#2756)
    • Bump com.diffplug.spotless from 6.10.0 to 6.11.0 (#2753)
    • Bump org.eclipse.osgi from 3.18.0 to 3.18.100 (#2751)
    • Bump versions.bytebuddy from 1.12.14 to 1.12.16 (#2747)
    Source code(tar.gz)
    Source code(zip)
  • v4.8.0(Sep 7, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.8.0

    • 2022-09-07 - 10 commit(s) by Alex, James Baker, Johannes Spangenberg, Kurt Alfred Kluever, Rafael Winterhalter, Thibault Helsmoortel, dependabot[bot]
    • GitHub Workflows security hardening (#2744)
    • Assign GlobalConfiguration initializer to unused variable (#2742)
    • Bump com.diffplug.spotless from 6.9.1 to 6.10.0 (#2738)
    • Drop varargs collector before invoking a user method. (#2736)
    • Bump versions.bytebuddy from 1.12.13 to 1.12.14 (#2734)
    • Remove useless thrown exception from constructor (#2732)
    • TypeSafeMatching no longer iterates over class methods inefficiently (#2729)
    • Fixes #2720: Use StackWalker on Java 9+ to create Locations (#2723)
    • LocationImpl adds performance overheads due to instantiating a stack trace (#2720)
    • Fixes #2626 : Introduce MockSettings.mockMaker (#2701)
    • Introduce option to disable inline-mock-maker for a specific instance (#2626)
    Source code(tar.gz)
    Source code(zip)
  • v4.7.0(Aug 13, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.7.0

    • 2022-08-13 - 33 commit(s) by 198812345678, Andy Coates, Chen Ni, Marius Lichtblau, Nikita Koselev. Developer Advocate, Open Source Ally, Rafael Winterhalter, dependabot[bot], dstango, fishautumn, heqiang
    • Bump com.diffplug.spotless from 6.9.0 to 6.9.1 (#2725)
    • Bump versions.bytebuddy from 1.12.12 to 1.12.13 (#2719)
    • Fix Javadoc for Mockito. (#2718)
    • Bump com.diffplug.spotless from 6.8.0 to 6.9.0 (#2717)
    • Fix a typo in comment of InternalRunner.java (#2715)
    • Bump junit-platform-launcher from 1.8.2 to 1.9.0 (#2713)
    • Bump versions.junitJupiter from 5.8.2 to 5.9.0 (#2712)
    • Bump groovy from 3.0.11 to 3.0.12 (#2711)
    • Bump shipkit-auto-version from 1.2.0 to 1.2.1 (#2709)
    • Bump kotlinVersion from 1.7.0 to 1.7.10 (#2705)
    • Bump com.diffplug.spotless from 6.7.2 to 6.8.0 (#2699)
    • Bump versions.bytebuddy from 1.12.11 to 1.12.12 (#2695)
    • Makes error message less misleading and points to github for help. Issue #2692 (#2693)
    • Misleading error message when mocking and a class (of a parameter) is not found (#2692)
    • Bump kotlinx-coroutines-core from 1.6.1-native-mt to 1.6.3-native-mt (#2691)
    • Bump versions.bytebuddy from 1.12.10 to 1.12.11 (#2690)
    • Fixes #2679 : Update Javadoc (#2689)
    • Bump org.eclipse.osgi from 3.17.200 to 3.18.0 (#2688)
    • RETURNS_SELF: Avoids returning mock when mock type is assignable to method return type, but method return type is Object. (#2687)
    • RETURNS_SELF breaks methods with generic return type (#2686)
    • Fix #2616 wrong stub for nested static (#2685)
    • Bump com.diffplug.spotless from 6.7.0 to 6.7.2 (#2684)
    • Avoids starting mocks "half-way" if a superclass constructor is mocked but an unmocked subclass is initiated. (#2682)
    • Fix typo (#2681)
    • Update javadoc of Strictness.STRICT_STUBS (#2679)
    • Bump kotlinVersion from 1.6.21 to 1.7.0 (#2677)
    • Bump biz.aQute.bnd.builder from 6.3.0 to 6.3.1 (#2675)
    • Bump biz.aQute.bnd.gradle from 6.3.0 to 6.3.1 (#2674)
    • Bump com.diffplug.spotless from 6.6.1 to 6.7.0 (#2672)
    • update CONTRIBUTING.md - stackoverflow (#2671)
    • stackoverflow.com is a non-actionable text, to be replaced with a hyperlink (#2670)
    • Fix typos (#2669)
    • Bump biz.aQute.bnd.gradle from 6.2.0 to 6.3.0 (#2666)
    • Bump biz.aQute.bnd.builder from 6.2.0 to 6.3.0 (#2665)
    • Improve Varargs handling in AdditionalAnswers (#2664)
    • Bump appcompat from 1.4.1 to 1.4.2 (#2663)
    • Varargs methods cause ClassCastException in AnswerFunctionalInterfaces (#2644)
    • Mock static class seems records wrong invocations if called nested method throws exception (#2616)
    Source code(tar.gz)
    Source code(zip)
  • v4.6.1(Jun 2, 2022)

  • v4.6.0(May 27, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.6.0

    • 2022-05-27 - 14 commit(s) by Hervé Boutemy, K. Siva Prasad Reddy, Rafael Winterhalter, dependabot[bot]
    • Bump shipkit-changelog from 1.1.15 to 1.2.0 (#2654)
    • Bump versions.errorprone from 2.13.1 to 2.14.0 (#2653)
    • Bump shipkit-auto-version from 1.1.20 to 1.2.0 (#2651)
    • Fixes #2648 : Add support for customising strictness via @Mock annotation and MockSettings (#2650)
    • Any way to enable Strict Stubbing when using Mockito.mock() without using @Mock? (#2648)
    • Reintroduce inheriting type annotations from interfaces if only one interface is mocked, including additional interfaces. (#2645)
    • Bump com.diffplug.spotless from 6.6.0 to 6.6.1 (#2643)
    • fix Reproducible Build issue (#2642)
    • Bump com.diffplug.spotless from 6.5.2 to 6.6.0 (#2641)
    • Mockito mock of interfaces lost annotation information (#2640)
    • Bump material from 1.5.0 to 1.6.0 (#2637)
    • Bump com.diffplug.spotless from 6.5.1 to 6.5.2 (#2636)
    • Bump versions.bytebuddy from 1.12.9 to 1.12.10 (#2635)
    • Bump com.diffplug.spotless from 6.5.0 to 6.5.1 (#2632)
    • Bump com.diffplug.spotless from 6.4.2 to 6.5.0 (#2631)
    Source code(tar.gz)
    Source code(zip)
  • v4.5.1(Apr 21, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.5.1

    • 2022-04-21 - 2 commit(s) by Jeremy Landis, dependabot[bot]
    • Fixes #2623: Use zulu distribution and java 11 for release GHA job (#2624)
    • Missing errorprone module for 4.5.0 in central as release was done with jdk 8 (#2623)
    • Bump kotlinVersion from 1.6.20 to 1.6.21 (#2622)

    Missing net.bytebuddy.utility.GraalImageCode exception

    If you encounter any issues with missing ByteBuddy classes, make sure you are using ByteBuddy 1.12 or higher.

    Source code(tar.gz)
    Source code(zip)
  • v4.5.0(Apr 19, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.5.0

    • 2022-04-19 - 15 commit(s) by Andrei Silviu Dragnea, Rafael Winterhalter, Rick Ossendrijver, dependabot[bot]
    • Bump versions.errorprone from 2.13.0 to 2.13.1 (#2621)
    • Bump versions.errorprone from 2.12.1 to 2.13.0 (#2619)
    • Groovy inline (#2618)
    • Bump actions/setup-java from 2 to 3 (#2615)
    • Bump versions.bytebuddy from 1.12.8 to 1.12.9 (#2614)
    • Support subclass mocks on Graal VM. (#2613)
    • Bump com.diffplug.spotless from 6.4.1 to 6.4.2 (#2611)
    • Bump kotlinx-coroutines-core from 1.6.0-native-mt to 1.6.1-native-mt (#2609)
    • Bump versions.errorprone from 2.10.0 to 2.12.1 (#2608)
    • Bump kotlinVersion from 1.6.10 to 1.6.20 (#2607)
    • Bump com.diffplug.spotless from 6.4.0 to 6.4.1 (#2606)
    • Bump com.diffplug.spotless from 6.3.0 to 6.4.0 (#2605)
    • Bump org.eclipse.osgi from 3.17.100 to 3.17.200 (#2597)
    • Deprecate ListUtil and Fields classes (#2593)
    • mockito-errorprone seems not compatible with ErrorProne 2.11.0 (#2554)
    • NullPointerException from Groovy metaclass methods when using mockito-inline (but not mockito-core) (#2522)
    Source code(tar.gz)
    Source code(zip)
  • v4.4.0(Mar 8, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.4.0

    • 2022-03-08 - 16 commit(s) by Andrew Kozel, Brice Dutheil, Jean-Baptiste Mille, Mirko Alicastro, dependabot[bot]
    • Bump groovy from 3.0.9 to 3.0.10 (#2586)
    • Bump google-java-format from 1.14.0 to 1.15.0 (#2585)
    • Bump actions/checkout from 2.4.0 to 3 (#2582)
    • Bump shipkit-auto-version from 1.1.19 to 1.1.20 (#2580)
    • Bump biz.aQute.bnd.builder from 6.1.0 to 6.2.0 (#2579)
    • Bump biz.aQute.bnd.gradle from 6.1.0 to 6.2.0 (#2578)
    • Adds a Google Java Format for JDK17 (#2572)
    • Clean up JUnit3 references (#2570)
    • Bump com.diffplug.spotless from 6.2.2 to 6.3.0 (#2567)
    • Bump google-java-format from 1.13.0 to 1.14.0 (#2565)
    • Bump versions.bytebuddy from 1.12.7 to 1.12.8 (#2564)
    • Bump com.diffplug.spotless from 6.2.1 to 6.2.2 (#2562)
    • Bump com.github.ben-manes.versions from 0.41.0 to 0.42.0 (#2559)
    • Bump com.diffplug.spotless from 6.2.0 to 6.2.1 (#2556)
    • Fixes #2548 : Makes InOrder able to verify static methods (#2549)
    • [PR open] Add feature to verify static methods calls in order (#2548)
    • Fixes #2201 : Fixed checking of declared exceptions. (#2547)
    • Calling getExceptionTypes() on concrete object that is used as interface doesn't return exception types from interface (#2201)
    Source code(tar.gz)
    Source code(zip)
  • v4.3.1(Jan 25, 2022)

  • v4.3.0(Jan 24, 2022)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.3.0

    • 2022-01-24 - 20 commit(s) by Andrew Kozel, John Pyeatt, Liam Miller-Cushon, Thomas Keller, Tim van der Lippe, dependabot[bot], temp-droid
    • Fixes #2489 : Fixed issue related to exceptions thrown from the nested spies (#2546)
    • Issue 2544 (#2545)
    • Bump versions.bytebuddy from 1.12.6 to 1.12.7 (#2543)
    • Bump com.diffplug.spotless from 6.1.2 to 6.2.0 (#2542)
    • Bump material from 1.4.0 to 1.5.0 (#2541)
    • Bump appcompat from 1.4.0 to 1.4.1 (#2539)
    • Bump com.diffplug.spotless from 6.1.1 to 6.1.2 (#2536)
    • Remove an @link (#2535)
    • Bump com.diffplug.spotless from 6.1.0 to 6.1.1 (#2534)
    • Bump com.github.ben-manes.versions from 0.40.0 to 0.41.0 (#2533)
    • Bump assertj-core from 3.21.0 to 3.22.0 (#2531)
    • Bump com.github.ben-manes.versions from 0.39.0 to 0.40.0 (#2529)
    • Bump com.diffplug.spotless from 6.0.5 to 6.1.0 (#2527)
    • Bump kotlinx-coroutines-core from 1.5.2-native-mt to 1.6.0-native-mt (#2526)
    • Bump versions.bytebuddy from 1.12.5 to 1.12.6 (#2524)
    • Bump com.diffplug.spotless from 6.0.4 to 6.0.5 (#2520)
    • Bump versions.bytebuddy from 1.12.4 to 1.12.5 (#2519)
    • Fixes #2510: Remove ExpectedException from internal test suite (#2518)
    • Fix JavaDoc warnings and enforce zero errors in Gradle (#2513)
    • Remove ExpectedException from internal test suite (#2510)
    • Incomplete stack trace returned from spy inside another spy (#2489)
    • Introduce a BOM for Mockito's artifacts (closes #2321) (#2323)
    • Provide a bill of materials (BOM) (#2321)
    Source code(tar.gz)
    Source code(zip)
  • v4.2.0(Dec 16, 2021)

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.2.0

    • 2021-12-16 - 21 commit(s) by Liam Miller-Cushon, Rafael Winterhalter, Tim van der Lippe, dependabot[bot], temp-droid
    • Update ByteBuddy to 1.12.4 (#2515)
    • Bump kotlinVersion from 1.6.0 to 1.6.10 (#2514)
    • Add DoNotMock mention to main JavaDoc (#2512)
    • Replace ExpectedException in MissingInvocationInOrderCheckerTest (#2511)
    • Update Gradle to version 7.3.1 (#2509)
    • Fixes #2497: Throw exception on invalid matchers for mockStatic (#2506)
    • Make sure interface types are initialized before inline mocking to avoid blocking code of static initializers. (#2505)
    • Bump org.eclipse.osgi from 3.17.0 to 3.17.100 (#2504)
    • Bump com.diffplug.spotless from 6.0.2 to 6.0.4 (#2501)
    • Bump com.diffplug.spotless from 6.0.1 to 6.0.2 (#2498)
    • ArgumentMatchers not working for Mockito.mockStatic (#2497)
    • Bump versions.bytebuddy from 1.12.2 to 1.12.3 (#2496)
    • Bump com.diffplug.spotless from 6.0.0 to 6.0.1 (#2495)
    • Remove the recommendation to import ArgumentMatchers methods using Mockito (#2494)
    • Bump versions.junitJupiter from 5.8.1 to 5.8.2 (#2491)
    • Bump junit-platform-launcher from 1.8.1 to 1.8.2 (#2490)
    • Fix typo 'DoNoMock' should be 'DoNotMock' (#2487)
    • Bump biz.aQute.bnd.gradle from 6.0.0 to 6.1.0 (#2486)
    • Bump biz.aQute.bnd.builder from 6.0.0 to 6.1.0 (#2485)
    • Bump versions.bytebuddy from 1.12.1 to 1.12.2 (#2484)
    • Bump google-java-format from 1.12.0 to 1.13.0 (#2483)
    • Add annotation to mark a type as DoNotMock (#1833)
    Source code(tar.gz)
    Source code(zip)
  • v4.1.0(Nov 19, 2021)

    Major new feature: @DoNotMock

    You can now mark classes/interfaces with @org.mockito.DoNotMock to disallow mocking with Mockito. For more information, see our documentation: https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/DoNotMock.html

    Changelog generated by Shipkit Changelog Gradle Plugin

    4.1.0

    • 2021-11-19 - 20 commit(s) by Lars Vogel, Mikaël Francoeur, S.YAMAMOTO, Tim van der Lippe, dependabot[bot]
    • Disable memory test (#2480)
    • Bump appcompat from 1.3.1 to 1.4.0 (#2477)
    • Bump kotlinVersion from 1.5.31 to 1.6.0 (#2474)
    • Bump versions.bytebuddy from 1.12.0 to 1.12.1 (#2472)
    • Bump com.diffplug.gradle.spotless from 4.5.1 to 6.0.0 (#2471)
    • Bump versions.bytebuddy from 1.11.22 to 1.12.0 (#2469)
    • Bump versions.errorprone from 2.9.0 to 2.10.0 (#2466)
    • Bump auto-service from 1.0 to 1.0.1 (#2463)
    • Bump actions/checkout from 2.3.5 to 2.4.0 (#2462)
    • Fixes #2460: Remove a sentence commits to a particular version (#2461)
    • Clarify Javadoc of RETURNS_SMART_NULLS, default answer in Mockito 4.0.0? (#2460)
    • Bump versions.bytebuddy from 1.11.21 to 1.11.22 (#2458)
    • Updated readme with the latest Mockito version (#2456)
    • Bump core-ktx from 1.6.0 to 1.7.0 (#2454)
    • Bump google-java-format from 1.11.0 to 1.12.0 (#2450)
    • Bump versions.bytebuddy from 1.11.20 to 1.11.21 (#2448)
    • Use new CodeCov uploader (#2447)
    • Bump actions/checkout from 2.3.4 to 2.3.5 (#2445)
    • Fixes #2389 : Parallel use of mocks with deep stubbing may lead to ConcurrentModificationException (#2444)
    • Bump versions.bytebuddy from 1.11.19 to 1.11.20 (#2443)
    • Parallel use of mocks with deep stubbing may lead to ConcurrentModificationException (#2389)
    • Add annotation to mark a type as DoNotMock (#1833)
    • Cannot mock this class: class java.io.InputStream with Java 13 (#1827)
    • Cannot mock wrapper types, String.class or Class.class (#1734)
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0(Oct 7, 2021)

    Mockito 4: Removing deprecated APIs.

    All of these APIs have been marked as deprecated and have been present in Mockito for quite a while.

    An overview of now-deleted classes/methods:

    • org.mockito.Matchers which was an alias for org.mockito.ArgumentMatchers
    • org.mockito.ArgumentMatchers#{anyObject,anyVararg} both which were aliases for org.mockito.ArgumentMatchers#any
    • org.mockito.ArgumentMatchers#any*Of, which were aliases for the same method name without the Of and the generic parameters (which were ignored)
    • org.mockito.ArgumentMatchers#{is}{Not}Null(Class) which took a class which was ignored. Aliases for the same methods without the parameter
    • org.mockito.MockedStatic#verify which had the parameter types reversed
    • org.mockito.Mockito#verifyZeroInteractions an alias of verifyNoMoreInteractions
    • org.mockito.Mockito#debug framework integration API that we later refactored
    • org.mockito.configuration.AnnotationEngine which was leaking internal APIs and instead users should use org.mockito.plugins.AnnotationEngine
    • org.mockito.exceptions.verification.TooLittleActualInvocations fixed the grammar from "Little" to "Few"
    • Numerous internal APIs that we never officially supported and can now remove
    • org.mockito.plugins.InstantiatorProvider which was leaking internal APIs and instead users should use InstantiatorProvider2 (we should probably rename back to remove the number in a future major release)
    • org.mockito.runners a package that hosted several old JUnit runners which were no longer supported. Users should instead use org.mockito.junit.MockitoJUnitRunner which is our official JUnit4 runner.
    Source code(tar.gz)
    Source code(zip)
  • v3.12.4(Aug 25, 2021)

  • v3.12.3(Aug 24, 2021)

  • v3.12.2(Aug 24, 2021)

  • v3.12.1(Aug 20, 2021)

  • v3.12.0(Aug 19, 2021)

    Changelog generated by Shipkit Changelog Gradle Plugin

    3.12.0

    • 2021-08-19 - 31 commit(s) by EugeneLesnov, Lars Vogel, Logan Rosen, Rafael Winterhalter, Rob Pridham, Tim van der Lippe, dependabot[bot], saurabh7248
    • Add checks for sealed types (#2392)
    • Bump versions.bytebuddy from 1.11.10 to 1.11.12 (#2388)
    • Bump versions.bytebuddy from 1.11.9 to 1.11.10 (#2387)
    • Bump versions.errorprone from 2.8.0 to 2.8.1 (#2386)
    • Update StaticMockTest to use unified verify method (#2385)
    • Reorder InjectMock Javadoc to fit the order of injection (#2383)
    • Bump core-ktx from 1.5.0 to 1.6.0 (#2382)
    • Bump google-java-format from 1.10.0 to 1.11.0 (#2381)
    • Downgrade Android gradle plugin (#2380)
    • Applied @CheckReturnValue to some classes (#2379)
    • how to solve gradle sync failed after 'Add basic Android instrumented and unit tests' (#2378)
    • Bump junit from 1.1.2 to 1.1.3 (#2377)
    • Bump appcompat from 1.3.0 to 1.3.1 (#2376)
    • Bump kotlin-gradle-plugin from 1.5.20 to 1.5.21 (#2374)
    • Bump material from 1.3.0 to 1.4.0 (#2373)
    • Bump espresso-core from 3.3.0 to 3.4.0 (#2372)
    • Fixes #2331 (#2369)
    • Fix typo in exception (#2368)
    • Bump versions.bytebuddy from 1.11.8 to 1.11.9 (#2367)
    • Bump versions.errorprone from 2.7.1 to 2.8.0 (#2365)
    • Bump versions.bytebuddy from 1.11.7 to 1.11.8 (#2361)
    • Basic Android instrumented and unit tests (closes #2341) (#2360)
    • Bump versions.bytebuddy from 1.11.6 to 1.11.7 (#2359)
    • Bump kotlin-stdlib from 1.5.20 to 1.5.21 (#2356)
    • Bump kotlinx-coroutines-core from 1.5.1 to 1.5.1-native-mt (#2354)
    • Bump kotlinx-coroutines-core from 1.5.0-native-mt to 1.5.1 (#2353)
    • Bump versions.bytebuddy from 1.11.5 to 1.11.6 (#2351)
    • Bump gradle-errorprone-plugin from 2.0.1 to 2.0.2 (#2347)
    • Bump kotlin-stdlib from 1.5.10 to 1.5.20 (#2343)
    • Bump versions.bytebuddy from 1.11.3 to 1.11.5 (#2337)
    • Bump assertj-core from 3.20.1 to 3.20.2 (#2336)
    • Spy doesn't forward hashcode/equals to actual object (#2331)
    • Fixes mockito#2311 (#2320)
    Source code(tar.gz)
    Source code(zip)
  • v3.11.2(Jun 21, 2021)

  • v3.11.1(Jun 11, 2021)

  • v3.11.0(Jun 3, 2021)

    Changelog generated by Shipkit Changelog Gradle Plugin

    3.11.0

    • 2021-06-03 - 18 commit(s) by Charles Munger, Szczepan Faber, dependabot[bot]
    • Bump versions.bytebuddy from 1.11.0 to 1.11.1 (#2313)
    • Undo parent for MultipleParentsClassLoader (#2312)
    • Bump shipkit-auto-version from 1.1.14 to 1.1.16 (#2310)
    • Bump gradle/wrapper-validation-action from 1.0.3 to 1.0.4 (#2309)
    • Bump com.github.ben-manes.versions from 0.38.0 to 0.39.0 (#2308)
    • Bump shipkit-auto-version from 1.1.11 to 1.1.14 (#2307)
    • Use the parent classloader if the context classloader is a child of it. (#2306)
    • Bump kotlin-stdlib from 1.5.0 to 1.5.10 (#2305)
    • "The type is not public and its mock class is loaded by a different class loader" with a context classloader that delegates (#2303)
    • Enabled automated changelog (#2301)
    • Bump kotlinx-coroutines-core from 1.4.3-native-mt to 1.5.0-native-mt (#2299)
    • Bump versions.errorprone from 2.6.0 to 2.7.1 (#2298)
    • Bump junit-platform-launcher from 1.7.1 to 1.7.2 (#2297)
    • Bump versions.junitJupiter from 5.7.1 to 5.7.2 (#2296)
    • Renamed main dev branch (#2295)
    • Bump gradle/wrapper-validation-action from 1 to 1.0.3 (#2294)
    • Bump actions/checkout from 2 to 2.3.4 (#2293)
    • 'this' is not available - when enabling mock-maker-inline (#2082)
    Source code(tar.gz)
    Source code(zip)
  • v3.10.0(May 12, 2021)

  • v3.9.10(Apr 29, 2021)

  • v3.9.9(Apr 29, 2021)

  • v3.9.7(Apr 23, 2021)

  • v3.9.3(Apr 14, 2021)

  • v3.9.2(Apr 12, 2021)

Owner
mockito
Mockito framework
mockito
Android library that allows you to run your acceptance tests written in Gherkin in your Android instrumentation tests.

Green Coffee Green Coffee is a library that allows you to run your acceptance tests written in Gherkin in your Android instrumentation tests using the

Mauricio Togneri 227 Nov 21, 2022
A micro mocking framework for KMP

Micro-Mock A micro Kotlin/Multiplatform Kotlin Symbol Processor that generates Mocks & Fakes. Limitations: Mocking only applies to interfaces Faking o

null 101 Jan 3, 2023
3 types of Tests in Android (Unit - instrumentation - UI)

UnitTestingPractice 3 types of Tests in Android Unit instrumentation (Integration) UI Unit Testing benefits confirm code work like a charm simulate Ap

Ahmed Tawfiq 8 Mar 23, 2022
A simple project to help developers in writing their unit tests in Android Platform.

AndroidUnitTesting A simple project to help developers in writing their unit tests in Android Platform. This is not a multi-module project, but has th

Bruno Gabriel dos Santos 4 Nov 10, 2021
PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to go

PowerMock 3.9k Jan 5, 2023
PowerMock is a Java framework that allows you to unit test code normally regarded as untestable.

Writing unit tests can be hard and sometimes good design has to be sacrificed for the sole purpose of testability. Often testability corresponds to go

PowerMock 3.9k Jan 2, 2023
Easy Response Mocking for Retrofit using annotations

Response Mocking for Retrofit using annotations. Assume Provides safe and easy way to mock API responses for retrofit-okhttp3.

Aniket Bhoite 25 Nov 16, 2021
mocking library for Kotlin

Kotlin Academy articles Check the series of articles "Mocking is not rocket science" at Kt. Academy describing MockK from the very basics of mocking u

MockK 4.8k Jan 3, 2023
Android Unit Testing Framework

Robolectric is the industry-standard unit testing framework for Android. With Robolectric, your tests run in a simulated Android environment inside a

Robolectric 5.6k Jan 3, 2023
Fixtures for Kotlin providing generated values for unit testing

A tool to generate well-defined, but essentially random, input following the idea of constrained non-determinism.

Appmattus Limited 191 Dec 21, 2022
Kotlin wrapper for React Test Renderer, which can be used to unit test React components in a Kotlin/JS project.

Kotlin API for React Test Renderer Kotlin wrapper for React Test Renderer, which can be used to unit test React components in a Kotlin/JS project. How

Xavier Cho 7 Jun 8, 2022
Easily scale your Android Instrumentation Tests across Firebase Test Lab with Flank.

Easily scale your Android Instrumentation Tests across Firebase Test Lab with Flank.

Nelson Osacky 220 Nov 29, 2022
Using grpc-wiremock to mock responses in integrated tests of gRPC services

Utilizando grpc-wiremock para mockar respostas em testes integrados de serviços gRPC Este repositório possui um exemplo prático de como configurar e r

Tony A. Luz 2 Oct 28, 2021
A library that makes it easier to write high quality automated acceptance tests

Getting started with Serenity and Cucumber Serenity BDD is a library that makes it easier to write high quality automated acceptance tests, with power

ricardo larrahondo 1 Oct 20, 2021
A JUnit5 Platform TestEngine integrated with the official FHIR Validator to run profile and Questionnaire validation as tests.

?? FHIR Validator JUnit Engine A JUnit5 TestEngine to integrate the FHIR Validator into the JUnit5 ecosystem. Supports writing expected validation out

NAV IT 2 Feb 2, 2022
Espresso - Use Espresso to write concise, beautiful, and reliable Android UI tests

Espresso Use Espresso to write concise, beautiful, and reliable Android UI tests

Android For All 1 Jan 26, 2022
Write Tests as Examples on the Method-under-test

Write Tests as Examples on the Method-under-test

Paul Methfessel 1 Apr 12, 2022
A collection of tests and easy to reuse pieces of code for bdk-jvm and bdk-android

Readme This repo is a collection of tests and easy to reuse pieces of code for bdk-jvm and bdk-android. Note that they don't aim to provide a full cov

thunderbiscuit 1 Jun 28, 2022
Automated tests using Rest-assured with Kotlin lang

Testes de API em Kotlin Pré-requisitos Instalar o Kotlin Ambiente Para executar os testes localmente, estou utilizando o ServeRest Link do Repo: https

Rafael Berçam 15 Dec 23, 2022