Testear flujos sin colgar el test

Un flujo frío que emite tres elementos y termina se comprueba con una línea, y esa facilidad engaña. El código interesante produce flujos que no terminan nunca: estados de pantalla, sesiones abiertas, resultados de búsqueda que se reemplazan, canales de eventos. Contra uno de esos, la operación de recolección no es una función que devuelve un valor sino una suspensión perpetua, y un test que la invoca sin más no falla ni pasa, se cuelga. Todas las técnicas de esta lección son variantes de la misma respuesta: introducir en el test una condición de salida que el flujo bajo prueba no tiene, y hacerlo sin alterar el comportamiento que estás comprobando.

Por qué un test de flujo se cuelga

La función de recolección es suspendida y solo retorna cuando el flujo se completa. Con un flujo frío finito eso ocurre enseguida; con un flujo caliente no ocurre jamás, y el test se queda dentro. La primera familia de soluciones consiste en envolver el flujo en un operador que le imponga un final artificial.

// Finito: sin problema
val lista = flowOf(1, 2, 3).toList()

// Infinito acotado por número de elementos
val tres = estadoDeLaPantalla.take(3).toList()

// Infinito acotado por una condición sobre el contenido
val cargado = estadoDeLaPantalla.first { it is Estado.Cargado }

Estas herramientas resuelven muchos casos y tienen dos puntos ciegos importantes. El primero: acotar por número exige saber de antemano cuántas emisiones habrá, y si el código emite una de menos el test vuelve a colgarse, ahora con una causa más difícil de leer. El segundo, más sutil: la recolección empieza cuando ejecutas la línea, así que cualquier emisión producida por una acción anterior ya se ha perdido. El patrón de disparar la acción y después recolectar es una condición de carrera escrita en dos líneas.

La segunda familia consiste en lanzar el colector como una corrutina independiente que se suscribe primero, ejecutar la acción después y cancelar el colector al final. Es correcto, pero exige colocar a mano el ámbito, el dispatcher y la cancelación en cada test.

@Test
fun publicaLosEstadosEnOrden() = runTest {
    val vistos = mutableListOf<Estado>()
    backgroundScope.launch(UnconfinedTestDispatcher(testScheduler)) {
        modelo.estado.collect { vistos += it }      // suscrito antes de actuar
    }

    modelo.buscar("kotlin")
    advanceUntilIdle()

    assertEquals(listOf(Estado.Inicial, Estado.Cargando, Estado.Cargado), vistos)
}

Turbine: emisiones como aserciones consumidas

Turbine invierte el modelo. En lugar de recolectar en una lista y comprobarla al final, abre un ámbito de prueba sobre el flujo que expone una cola de eventos, y el test va extrayendo eventos uno a uno con funciones suspendidas que esperan lo justo. La aserción y la espera son la misma operación.

@Test
fun emiteCargandoYDespuesElResultado() = runTest {
    modelo.estado.test {
        assertEquals(Estado.Inicial, awaitItem())
        modelo.buscar("kotlin")
        assertEquals(Estado.Cargando, awaitItem())
        assertEquals(Estado.Cargado(listOf("Kotlin in Action")), awaitItem())
        cancelAndIgnoreRemainingEvents()
    }
}

La propiedad que hace valiosa a esta biblioteca no es la comodidad sintáctica sino una regla de higiene que impone sin pedir permiso: al cerrar el bloque, si quedan eventos sin consumir el test falla. Eso convierte una emisión de más —el bug clásico de un estado publicado dos veces, o de un Cargando que reaparece tras el resultado— en un fallo explícito, cuando con una lista y una comparación al final habría pasado desapercibido o habría producido un mensaje ilegible.

flowchart TD
A[Abrir bloque de prueba sobre el flujo] --> B[Suscripcion inmediata]
B --> C[Cola de eventos]
C --> D[awaitItem consume uno]
D --> E{Quedan eventos al cerrar}
E -->|No| F[Test correcto]
E -->|Si| G[Fallo por evento no consumido]
C --> H[awaitComplete o awaitError]
H --> F

StateFlow: conflación, igualdad y suscripción

Un StateFlow no es un flujo con memoria: es un contenedor de estado observable, y esa diferencia cambia por completo qué emisiones puede ver un colector. Tres reglas la gobiernan y las tres sorprenden la primera vez.

La primera es que el valor actual se entrega siempre al suscribirse, así que el primer elemento que recibe cualquier colector es el estado en el momento de la suscripción, no la siguiente actualización. La segunda es que las emisiones están confladas: si el valor cambia dos veces antes de que el colector procese la primera, la intermedia desaparece sin dejar rastro. La tercera es que las asignaciones se filtran por igualdad estructural, de modo que asignar un valor igual al actual no produce emisión alguna.

@Test
fun laConflacionSeComeElEstadoIntermedio() = runTest {
    val estado = MutableStateFlow(0)

    estado.test {
        assertEquals(0, awaitItem())     // valor actual al suscribirse
        estado.value = 1
        estado.value = 2                 // el 1 puede no llegar nunca
        assertEquals(2, awaitItem())
        estado.value = 2                 // igual al actual: no emite
        expectNoEvents()
        cancelAndIgnoreRemainingEvents()
    }
}

De ahí se sigue una consecuencia de diseño que va más allá del test: un StateFlow es correcto para representar estado y equivocado para transportar eventos. Si tu pantalla necesita saber que hubo dos errores seguidos, y ambos producen un valor estructuralmente igual, el segundo no llegará nunca; con una data class, la igualdad que genera el compilador es precisamente lo que provoca esa pérdida.

Queda el caso del estado derivado con stateIn y una política de suscripción, muy común en modelos de vista. Con la política que mantiene la fuente activa mientras haya suscriptores, el flujo de origen no arranca hasta que alguien colecta, y además sigue vivo durante un margen tras el último suscriptor. En un test eso significa que sin colector no ocurre absolutamente nada, y que el margen se mide en tiempo virtual y por tanto debes hacerlo avanzar si quieres observar el reinicio.