Dobles de prueba: clases finales, all-open y fakes escritos a mano

El choque entre Kotlin y las bibliotecas de mocking heredadas de Java es una colisión entre dos filosofías, no un fallo de compatibilidad. El mocking clásico funciona generando en tiempo de ejecución una subclase que redefine todos los métodos, y esa técnica presupone que cualquier clase se puede extender y cualquier método se puede redefinir, que es exactamente lo que Kotlin decidió negar por defecto. Cuando una herramienta te informa de que no puede simular una clase final, no está señalando una carencia del lenguaje: está revelando que tu test necesitaba una capacidad que el diseño de tu código declara inexistente, y a partir de ahí solo hay dos caminos honestos, cambiar el diseño o desactivar la garantía.

Final por defecto y el mocking por subclase

Una clase de Kotlin sin el modificador open se compila como final, y sus métodos también. La justificación de ese valor por defecto es el problema de la clase base frágil: heredar de una clase no diseñada para ser heredada acopla al hijo a detalles internos que el autor nunca prometió mantener. Por añadidura, la finalidad permite al compilador y a la máquina virtual devirtualizar llamadas e insertarlas en línea con más agresividad.

Las bibliotecas de mocking tradicionales operan justo en la dirección contraria. Para crear un doble de una clase, generan en tiempo de ejecución una subclase cuyos métodos redefinidos consultan una tabla de comportamientos configurados. Sobre una clase final esa generación es imposible, y el resultado es un error en el momento de crear el doble.

// Producción: final por defecto, tal y como debe ser
class CalculadoraDeEnvio(private val tarifas: TablaDeTarifas) {
    fun coste(peso: Int): Int = tarifas.para(peso) + 250
}

// El doble por subclase no puede existir sobre esta clase

Las salidas técnicas son dos y ambas consisten en dejar de usar subclases. La primera es la instrumentación: agentes que reescriben el bytecode de la clase real en el momento de cargarla, sustituyendo los cuerpos de sus métodos por desvíos hacia la tabla de comportamientos. Así funcionan el generador en línea de Mockito y la biblioteca idiomática de Kotlin para este fin, que además de clases finales puede simular declaraciones object, funciones de nivel superior y extensiones. La segunda es el plugin all-open, que actúa antes, en compilación.

all-open para tests y su factura

El plugin all-open elimina el modificador final de las clases y los miembros que lleven determinadas anotaciones. Es la maquinaria que hace funcionar a Spring con Kotlin sin obligar a marcar cada componente como abierto, y se puede reutilizar para tests declarando una anotación propia sin significado semántico.

// Definición de la marca
annotation class AbiertoParaPruebas

// build.gradle.kts
plugins { kotlin("plugin.allopen") version "2.2.0" }
allOpen { annotation("com.ejemplo.AbiertoParaPruebas") }

@AbiertoParaPruebas
class CalculadoraDeEnvio(private val tarifas: TablaDeTarifas) {
    fun coste(peso: Int): Int = tarifas.para(peso) + 250
}

Conviene ser exacto sobre lo que acaba de ocurrir, porque el discurso habitual lo presenta como una configuración inocua. La clase ya no es final en el artefacto que llega a producción: cualquiera puede heredarla, la máquina virtual pierde la garantía que usaba para devirtualizar, y el compilador de Kotlin deja de aplicar optimizaciones que dependían de la finalidad. La anotación dice abierto para pruebas, pero el bytecode dice abierto, sin más.

La variante que intenta limitar el daño consiste en aplicar el plugin únicamente en una variante de compilación destinada a pruebas, de modo que el binario de producción conserve la finalidad. Es viable en proyectos con sabores de compilación, pero introduce una asimetría incómoda: el código que ejecutan los tests no es exactamente el que se despliega, y la diferencia recae precisamente sobre la propiedad de la que dependen las optimizaciones y el polimorfismo.

Interfaces y fakes: la salida que además mejora el diseño

En un proyecto multiplataforma la discusión anterior se cierra sola: Kotlin/Native no tiene reflexión ni carga dinámica de clases, JS y Wasm tampoco tienen bytecode que reescribir, y por tanto ninguna biblioteca basada en manipulación en tiempo de ejecución puede vivir en commonTest. Existen generadores de dobles basados en procesamiento de símbolos que producen el código en compilación, y precisamente por eso solo pueden sustituir interfaces y clases abiertas: han vuelto al mismo requisito del que se intentaba escapar.

La alternativa que funciona en todas partes es declarar la dependencia como interfaz e implementarla dos veces, una para producción y otra para pruebas. El doble de pruebas no simula: funciona.

interface TablaDeTarifas {
    fun para(peso: Int): Int
}

class TarifasFalsas(private val precios: Map<Int, Int> = emptyMap()) : TablaDeTarifas {
    var consultas = 0
        private set

    override fun para(peso: Int): Int {
        consultas++
        return precios[peso] ?: (peso * 10)
    }
}

@Test
fun anadeLaComisionFija() {
    val tarifas = TarifasFalsas(mapOf(5 to 1_000))
    assertEquals(1_250, CalculadoraDeEnvio(tarifas).coste(5))
    assertEquals(1, tarifas.consultas)
}

Un fake bien hecho tiene una propiedad que ningún doble configurado en el test posee: es una implementación coherente, así que un repositorio falso en memoria devuelve lo que se le guardó, respeta sus propias invariantes y falla igual que el real ante entradas inválidas. Eso permite comprobar estado —qué quedó guardado, qué se devolvió— en lugar de interacción —qué método se llamó y con qué argumentos—, y la diferencia es decisiva: las aserciones sobre interacciones se rompen en cada refactorización que no cambia el comportamiento, que es exactamente el tipo de cambio que los tests deberían proteger.

Hay, eso sí, una familia de casos donde la interacción sí forma parte del contrato y comprobarla es legítimo: cuando el efecto observable del sistema es precisamente la llamada. Que se envíe exactamente un correo, que no se cobre dos veces al mismo cliente o que se registre un evento de auditoría por cada acceso son afirmaciones sobre la interacción, y un fake puede sostenerlas sin dejar de ser un fake, sin más que llevar la cuenta por dentro.

Y hay una simplificación que se pasa por alto con demasiada frecuencia. Si el rol que necesitas sustituir tiene una sola operación, no hace falta declarar una interfaz ni escribir una clase: un tipo función es un doble perfectamente válido, se sustituye con una lambda y no obliga a nadie a inventar un nombre para un concepto que no existe.

class CalculadoraDeEnvio(private val tarifaDe: (Int) -> Int) {
    fun coste(peso: Int): Int = tarifaDe(peso) + 250
}

@Test
fun usaLaTarifaRecibida() =
    assertEquals(1_250, CalculadoraDeEnvio { 1_000 }.coste(5))

flowchart TD
A[Necesito sustituir una dependencia] --> B{Es una interfaz}
B -->|Si| C[Fake escrito a mano]
C --> D[Funciona en los cuatro objetivos]
B -->|No, clase final| E{Proyecto multiplataforma}
E -->|Si| F[Extraer interfaz, no hay otra via]
E -->|No| G{Puedo cambiar el diseno}
G -->|Si| F
G -->|No| H[Instrumentacion o plugin all-open]
H --> I[Deuda tecnica acotada y documentada]