Mockito-Kotlin

When running benchmarks, you can customize the number of warmup and measured iterations using system properties. If not specified, the defaults are 100 warmup iterations and 1000 measured iterations.

./gradlew :benchmarks:test --rerun \
  -Dbenchmark.iterations=5000 \
  -Dbenchmark.warmup=500

You can run the lightweight comparative benchmarks between mockito-kotlin and MockK using the Gradle wrapper. These benchmarks measure the cost of common mocking use cases like basicMocking, heavyMocking, and objectMocking across cold start and warm average iterations.

./gradlew :benchmarks:test --rerun

Mockito-Kotlin provides a DSL to configure mock behavior using the on { ... } doReturn syntax. You can initiate stubbing using either the stubbing(mock) { ... } function or by calling .stub { ... } directly on a mock object.

This DSL supports both synchronous and suspendable (coroutine) function calls.

Mockito-Kotlin provides helper functions like mock<T> and doReturn to provide a more idiomatic Kotlin experience when using Mockito. You can define mock behavior within a configuration block using on { ... } doReturn ....

@Test
fun doAction_doesSomething(){
  /* Given */
  val mock = mock<MyClass> {
    on { getText() } doReturn "text"
  }
  val classUnderTest = ClassUnderTest(mock)
  
  /* When */
  classUnderTest.doAction()
  
  /* Then */
  verify(mock).doSomething(any())
}

When stubbing methods that return generic types, use onGeneric() to provide the necessary type information. This is required because the Kotlin type system may struggle to infer the return type of a generic method during stubbing.

Note: This is a specialized function for handling generic return types R where you may need to pass a KClass<R>.

interface GenericMethods<T> {
    fun genericMethod(): T
}

// Stubbing a generic method
mock<GenericMethods<Int>> {
    onGeneric({ genericMethod() }, Int::class) doReturn 10
}

Reverse stubbing allows you to define behavior (like throwing an exception) as part of the mock creation process. This is particularly useful for stubbing Unit functions or void methods. It uses an infix function on on a Stubber object.

Example usage:

mock<SynchronousFunctions> {
    doThrow(RuntimeException()).on { string("test") }
}

Use the verify(mock) { ... } DSL to verify interactions on a mock. This syntax allows for a more readable way to specify the number of times a method was called using the times operator (multiplication syntax) within the block.

To verify that a method was called a specific number of times, use the syntax N * { methodCall() } inside the verify block, where N is an Int.

verify(mock) {
    2 * { call() }
}

A MockedObject implements the ScopedMock interface, allowing you to manage its lifecycle. You can check if the mock is still active or manually release the resources to prevent memory leaks or interference with other tests.

• isClosed(): Returns true if the underlying singleton mock is closed.
• close(): Closes both the static and singleton mocks.
• closeOnDemand(): Schedules the mocks to be closed when they are no longer needed.

The KInvocationOnMock class wraps Mockito's InvocationOnMock to provide Kotlin-friendly destructuring support. It allows you to use Kotlin's destructuring syntax to quickly access arguments passed to a mock during an Answer implementation.

By using the componentN() operators, you can extract the first five arguments (indices 0 to 4) directly into variables.

The on() function is used to specify which method call should be stubbed. It is an alias for Mockito.when and can be used in two ways:

1. Passing the method call directly: on(mock.someFunction())
2. Passing a lambda: on { mock.someFunction() } (This is preferred for Kotlin-specific features like suspend functions).

Returns an OngoingStubbing object which is then used with doReturn, doThrow, etc. Do not create a reference to the returned OngoingStubbing object.