MockK: qué es, conceptos clave y sintaxis

¿Qué es MockK?

MockK es una biblioteca para crear objetos mock, escrita en Kotlin y optimizada para su sintaxis. Resuelve los mismos problemas que Mockito — aislar el código probado de las dependencias — pero lo hace utilizando construcciones específicas de Kotlin: lambdas, DSL, reified generics y funciones suspend.

La principal ventaja de MockK sobre las soluciones portadas es el soporte nativo de Kotlin. En Mockito, simular una clase final requiere opt-in (mockito-inline), y los métodos estáticos requieren mockStatic. MockK lo admite de forma predeterminada, ya que las clases de Kotlin son final por defecto, y la omisión de esta limitación está integrada en la arquitectura de la biblioteca.

La versión 1.13.12 (2024) es una versión estable que admite Kotlin 2.0, el compilador K2 y proyectos multiplataforma (KMP). MockK también funciona con Kotlin/Native y Kotlin/JS, lo que lo convierte en la única opción para proyectos KMP donde ni Mockito ni EasyMock son aplicables.

MockK está diseñado teniendo en cuenta las particularidades de Kotlin y utiliza las características del lenguaje — reified generics, DSL con lambdas, funciones inline — para proporcionar una API concisa y type-safe sin sacrificar el rendimiento.

Cómo funciona MockK

El mecanismo de MockK se basa en la instrumentación de bytecode a través de la biblioteca ByteBuddy (como Mockito), pero la envuelve en un DSL amigable con Kotlin. En lugar de cadenas when().thenReturn(), MockK utiliza bloques lambda every { } y coEvery { } que parecen una extensión natural del lenguaje. Internamente, MockK intercepta la llamada dentro de la lambda, analiza el método y los argumentos mediante reflexión y los compara con las reglas de stubbing registradas.

Sintaxis básica de MockK

El bloque every { mock.method() } returns value se lee como “cada vez que se llama al método, devolver el valor.” Esta sintaxis declarativa está más cerca del estilo Kotlin y elimina la confusión con el orden de los argumentos en when(). Gracias a los reified generics de Kotlin, el tipo de mock se infiere automáticamente sin especificar explícitamente la clase.

val repository = mockk<UserRepository>()

// Stubbing: cada llamada a findById(1) devuelve el usuario
every { repository.findById(1) } returns User("Alice")

// Llamada y verificación
val result = repository.findById(1)
assertEquals("Alice", result.name)

Relaxed mock: menos código repetitivo

A diferencia de Mockito, donde cada método debe configurarse explícitamente, MockK admite relaxed mock — un mock que devuelve valores predeterminados “razonables” para cualquier método: una lista vacía para List, 0 para Int, una cadena vacía para String. Esto reduce drásticamente la cantidad de código de preparación.

// Relaxed mock — todos los métodos devuelven valores predeterminados
val api = mockk<ApiService>(relaxed = true)

// No requiere stubbing — devuelve una lista vacía
println(api.getUsers()) // []

Creación de mocks y mocks relajados

MockK ofrece varias formas de crear objetos mock: mockk<T>() para mocks estrictos (cada método debe configurarse explícitamente), mockk<T>(relaxed = true) para mocks relajados y spyk(obj) para crear un espía sobre un objeto real.

La elección entre mock estricto y relajado depende del contexto. Un mock estricto garantiza que la prueba no utilice métodos cuyo comportamiento no esté definido — esto aumenta la fiabilidad. Un mock relajado es conveniente para la creación rápida de prototipos de pruebas donde no todas las dependencias son importantes. En la práctica, se recomienda comenzar con un mock estricto y cambiar a relajado solo cuando el stubbing ocupa más líneas que la prueba misma.

Stubbing: configuración del comportamiento con el bloque every

El bloque every es la construcción central de stubbing en MockK. Dentro de la lambda, se describe una llamada a un método con argumentos específicos, y luego se devuelve un valor mediante returns, se lanza una excepción mediante throws o se calcula una respuesta mediante answers.

Diferentes formas de stubbing

MockK admite todos los escenarios necesarios para las pruebas: devolver un valor, lanzar una excepción, calcular una respuesta basada en argumentos y múltiples respuestas en orden (secuencia de llamadas).

// Devolver valor
every { repo.findById(1) } returns User("Alice")

// Lanzar excepción
every { repo.findById(999) } throws NotFoundException()

// Respuesta dinámica
every { repo.save(any()) } answers {
    val user = firstArg<User>()
    user.copy(id = 42)
}

// Secuencia de respuestas
every { repo.findAll() } returnsMany listOf(
    listOf(User("Alice")),
    listOf(User("Bob")),
    emptyList()
)

Verify y coVerify para corrutinas

Verify en MockK es similar a Mockito.verify() en propósito, pero utiliza DSL de Kotlin: verify { mock.method() }. Para funciones suspend se utiliza coVerify { mock.suspendMethod() }, que funciona correctamente con corrutinas y no requiere un ejecutor especial.

Verificación del número de llamadas

MockK admite los mismos modificadores que Mockito: exactly(1), atLeast(2), atMost(5), wasNot(Called). La sintaxis es minimalista — el modificador se pasa como primer argumento en verify { }.

// Verificación: método llamado exactamente 1 vez
verify(exactly = 1) { repo.save(any()) }

// Verificar orden de llamadas
verifySequence {
    repo.save(any())
    repo.flush()
}

// coVerify para funciones suspend
coVerify { api.fetchUsers() }

Slot: captura de argumentos

Para la verificación de argumentos se utiliza slot() — un análogo de ArgumentCaptor. Un slot se declara antes de la llamada, se pasa a every o verify, y después de la ejecución de la prueba contiene el valor capturado.

val userSlot = slot<User>()

verify { repo.save(capture(userSlot)) }

assertEquals("Alice", userSlot.captured.name)

Anotaciones de MockK e integración con JUnit

MockK proporciona las anotaciones @MockK y @RelaxedMockK para crear mocks mediante inicialización en JUnit 5. La extensión MockKExtension crea automáticamente mocks antes de cada prueba y los limpia después — similar a MockitoExtension, pero con soporte para modo relajado.

Ejemplo con MockKExtension

La anotación @InjectMockKs (o la alternativa @MockK con creación explícita de objetos) inyecta mocks en la instancia probada. Esto reduce el código repetitivo y hace que el código de la prueba sea más limpio.

@ExtendWith(MockKExtension::class)
class UserServiceTest {

    @MockK
    lateinit var repository: UserRepository

    @InjectMockKs
    lateinit var service: UserService

    @Test
    fun `getUser returns user from repository`() {
        every { repository.findById(1) } returns User("Alice")
        assertEquals("Alice", service.getUser(1)?.name)
    }
}

MockK vs Mockito: qué elegir para Kotlin

La elección entre MockK y Mockito depende de la composición del equipo y del tipo de proyecto. Mockito tiene un ecosistema más grande, más ejemplos y más integraciones, pero MockK proporciona una sintaxis Kotlin más limpia y soporte nativo para las características del lenguaje. Para proyectos nuevos en Kotlin, se recomienda MockK como la solución más idiomática.

Para proyectos en Kotlin puro (sin clases Java), MockK es preferible: menos código repetitivo, soporte nativo de corrutinas, sin sorpresas con clases final. Para proyectos híbridos o equipos con experiencia en Java, Mockito sigue siendo una opción viable — ambas bibliotecas se pueden usar en el mismo proyecto a través de diferentes módulos. Al migrar de Mockito a MockK, basta con reemplazar las anotaciones @Mock por @MockK y reescribir los bloques when().thenReturn() al formato every { }.