Por qué esto encuentra bugs reales

Casi todos los bugs de estado que llegan a producción comparten una biografía: nadie los escribió a propósito. No son errores de lógica que alguien razonó mal, sino efectos laterales de un cambio hecho en otro sitio —un campo que alguien añadió a la mutación de una acción vecina, un efecto que se disparó dos veces porque una rama nueva no cancelaba la anterior, una hoja modal que se cerró dejando dentro los datos del intento anterior—. Y comparten también su forma de esconderse: son cambios que ocurren de verdad, en el momento adecuado, sin lanzar ninguna excepción, y que sólo se manifiestan cuando el usuario hace las cosas en un orden que nadie probó. Un test convencional no puede verlos porque sólo mira lo que su autor decidió mirar, y ningún autor decide mirar aquello que no sabe que existe. Esta lección sostiene que ahí, y no en la confirmación del camino feliz, está el valor entero del TestStore: no sirve para comprobar lo que quisiste hacer, sirve para delatar lo que hiciste sin darte cuenta.

El bug que ningún otro test puede ver

Considera un cambio inocente. Alguien añade una analítica a la pantalla y decide, de paso, contar cuántas veces el usuario pulsa el botón de guardar. Escribe una línea dentro de la rama que ya existía.

case .guardarPulsado:
  state.guardando = true
  state.pulsaciones += 1        // linea nueva, aparentemente inofensiva
  return .run { send in
    await send(.guardado(try await api.guardar(state.borrador)))
  }

Un test convencional de esa pantalla comprueba que al pulsar guardar el indicador se enciende y que al volver la respuesta se apaga. Sigue verde. La app se comporta igual en el simulador. Y sin embargo el estado ya no es el que la prueba describía: hay un campo que se mueve y nadie lo ha declarado en ninguna parte. Hoy es un contador inofensivo; dentro de tres meses ese mismo campo participa en una comparación de Equatable que decide si una vista se redibuja, o se persiste, o viaja a una feature padre, y entonces el incremento silencioso se convierte en un redibujado por pulsación, en un dato corrupto en disco o en una animación que se dispara sola. En el TestStore esa línea no llega a mañana: la prueba se pone roja en el mismo commit, con un diff que dice + $0.pulsaciones = 1, y quien la lee tiene que decidir si ese cambio es querido y documentarlo, o no lo es y borrarlo.

Y conviene notar de dónde venía el cambio: no de un descuido, sino de una petición razonable hecha por alguien que no conocía el resto de la feature. Los bugs de estado no intencionados casi nunca nacen de la ignorancia técnica, nacen de la asimetría de información entre quien edita una rama y quien conoce las consecuencias de ese campo tres módulos más allá. Ninguna revisión de código cubre esa asimetría de forma fiable, porque el revisor lee el diff y el diff parece correcto; lo que la cubre es una descripción del comportamiento que la máquina evalúa entera cada vez.

Aquí está la asimetría que define el capítulo. Un test parcial verifica una hipótesis: «si hago esto, aquello vale tal cosa». Sólo puede fallar si la hipótesis se rompe, y las hipótesis que alguien escribió cubren, en el mejor de los casos, lo que ese alguien había imaginado. Un test exhaustivo verifica una descripción cerrada: «tras esto, el estado es exactamente este y no ha vuelto nada más». Puede fallar por cosas que su autor jamás imaginó, y ese es literalmente el conjunto de los bugs no intencionados.

Seis patrones que la exhaustividad caza

La columna de la derecha es la que explica por qué esta familia sobrevive a todas las demás defensas. Ninguno de los seis produce una excepción, ninguno rompe una invariante que el compilador pueda comprobar y ninguno se manifiesta de forma fiable al usar la app a mano, porque todos dependen de una secuencia concreta —abrir dos veces, escribir rápido, perder la red a mitad— que nadie ejecuta por casualidad. Son, en sentido estricto, fallos de estado y no de código: el programa hace lo que dice hacer en cada línea, y aun así el mundo que va quedando detrás no es el que debería.

Merecen un comentario los dos que más daño hacen. El efecto de más es traicionero porque su síntoma no es un valor incorrecto sino un consumo doble: dos peticiones al servidor, dos escrituras en disco, dos eventos de analítica. El resultado final es idéntico, así que ninguna aserción sobre el estado lo delata; lo delata la cola del TestStore, que se queda con una acción sin reclamar y obliga a preguntarse de dónde salió esa segunda respuesta. El estado sin limpiar es el bug clásico de las hojas modales y los formularios: la feature hija se cierra y su estado se conserva, de modo que al reabrirla aparece el borrador anterior, o el mensaje de error de la vez pasada, o el resultado de una validación caducada. En el simulador hay que abrir, cerrar y reabrir para verlo; en el TestStore aparece a la primera, porque tras la acción de cierre tienes que declarar exactamente qué queda del hijo y ahí, al escribirlo, es cuando uno descubre que queda todo.

Un caso real: la hoja que recuerda demasiado

Vale la pena seguir uno de esos patrones hasta el final, porque enseña algo que la lista no puede enseñar: que el fallo de la prueba suele apuntar a un defecto de modelado y no a una línea mal escrita.

@ObservableState
struct State: Equatable {
  var mostrandoHoja = false
  var borrador = Borrador()      // vive en el padre, fuera de la hoja
  var error: String?
}

case .cerrarHojaPulsado:
  state.mostrandoHoja = false    // y nada mas
  return .none

Al escribir la prueba del flujo completo llega el momento de declarar el estado tras reabrir la hoja, y ahí se ve lo que en el simulador nadie mira:

await store.send(.abrirHojaPulsado) { $0.mostrandoHoja = true }
await store.send(.tituloCambio("a medias")) { $0.borrador.titulo = "a medias" }
await store.send(.cerrarHojaPulsado) { $0.mostrandoHoja = false }

await store.send(.abrirHojaPulsado) {
  $0.mostrandoHoja = true
  // y el borrador sigue diciendo "a medias": hay que escribirlo o no compila el enunciado
}

Nadie miente en ese test y sin embargo la tercera línea documenta un bug: el usuario cerró la hoja y su texto sobrevivió. La corrección no consiste en añadir un state.borrador = Borrador() en la rama de cierre —eso es tapar el síntoma y olvidarlo en la siguiente rama que cierre la hoja— sino en mover el borrador dentro del estado del hijo y modelar la presentación con @Presents, de modo que poner el opcional a nil destruya el borrador por construcción y no por acordarse. La prueba no ha encontrado una línea que falta: ha encontrado un estado mal colocado, y ha señalado el sitio exacto donde vivía la confusión.

El coste, dicho con honestidad

Sería deshonesto vender la exhaustividad como gratis. Cuesta escribir más: cada acción exige su declaración de estado, cada efecto su recepción, cada tarea su cierre. Cuesta mantener: un cambio deliberado de comportamiento rompe varias pruebas a la vez y hay que actualizarlas todas. Y produce un tipo particular de fatiga, la de ver rojo por cosas que sabes que están bien —el contador de analítica que sí querías, el campo nuevo que sí debía moverse—, con la tentación consiguiente de bajar la exigencia por sistema.

// El fallo util y el fallo molesto se ven igual; solo tu sabes cual es cual
await store.send(.guardarPulsado) {
  $0.guardando = true
  $0.pulsaciones = 1      // ¿lo añades porque lo querias o porque el test se queja?
}

Hay además un coste que casi nunca se menciona y que es el más real de todos: la exhaustividad hace visible cuánto acoplamiento tiene tu feature. Una prueba que se rompe entera cada vez que tocas un campo no está siendo severa, está diciéndote que ese campo participa en demasiadas transiciones; un flujo que exige veinte líneas de aserción por paso está confesando que su estado mezcla cosas que deberían vivir separadas. Leído así, el dolor de mantener la prueba no es un impuesto sobre el testing sino una señal de diseño llegando por el único canal que no se puede ignorar, y la reacción productiva no es relajar la aserción sino partir el estado.

La respuesta a esa tentación no es doctrinal sino económica, y conviene formularla como una comparación de costes: escribir una línea de aserción de más cuesta segundos; encontrar en producción un bug de estado no intencionado cuesta, en el mejor de los casos, una tarde de reproducción a ciegas y, en el peor, datos corruptos en los dispositivos de los usuarios. La exhaustividad traslada trabajo desde el momento en que es carísimo —el diagnóstico a posteriori, sin contexto y con presión— al momento en que es baratísimo: ahora, con el código delante y la intención todavía fresca en la cabeza. Ese traslado es todo el negocio.

flowchart TD
C[Cambio en el reducer] --> Q{Fue intencionado}
Q -->|si| D[Actualizas la asercion y queda documentado]
Q -->|no| B[Bug detectado en el commit]
D --> V[Verde con la especificacion al dia]
B --> F[Lo borras antes de que llegue a produccion]
style V fill:#a6e3a1,color:#11111b
style B fill:#f9e2af,color:#11111b