TestStore: testing exhaustivo

Casi cualquier framework te deja escribir tests; TCA te obliga a que sean exhaustivos. Su TestStore no es un ayudante opcional sino un juez implacable: por cada acción que le envías exige que declares exactamente cómo quedó el estado —campo a campo— y que recibas, uno a uno, todos los efectos que esa acción disparó. Si el estado cambia en algo que no afirmaste, el test falla. Si un efecto devuelve una acción que no recibiste, el test falla. Si al terminar queda una tarea en vuelo, el test falla. Esta severidad, que al principio irrita, es el mecanismo: un test que pasa en el TestStore es una descripción completa y verificada de lo que la feature hace, sin un solo hueco donde pueda esconderse un cambio no intencionado.

send: declarar el estado, no observarlo

La primera sorpresa del TestStore es que no le preguntas cómo quedó el estado: se lo dices, y él comprueba si acertaste. Al enviar una acción con send pasas una closure que recibe una copia del estado anterior; tu labor es mutarla hasta dejarla como esperas que quede después. Por dentro, el TestStore corre el reducer real sobre su propia copia y compara ambos resultados campo a campo.

@Test
func incremento() async {
  let store = TestStore(initialState: Contador.State()) {
    Contador()
  }
  await store.send(.incrementar) {
    $0.cuenta = 1
  }
}

La closure no observa el estado, lo predice. Si escribieras $0.cuenta = 2, la comparación fallaría con un diff que enfrenta lo esperado contra lo real. Y aquí aparece la exhaustividad: si el reducer cambiara además otro campo —digamos $0.ultimoToque— y tú no lo declararas en la closure, el test también falla. No basta con acertar lo que miras; hay que dar cuenta de todo lo que se movió. Omitir la closure cuando el estado sí cambió es el error que el TestStore te obliga a no cometer.

La simetría inversa también se vigila: si adjuntas una closure a una acción que no alteró el estado, el TestStore protesta igual, porque una aserción redundante miente sobre lo que ocurre tanto como una omitida. La regla es exacta en ambas direcciones —hay closure si y solo si hubo mutación—, y esa exactitud de doble filo es lo que impide que el test acumule ruido inofensivo en apariencia o esconda un cambio real entre líneas que nadie vuelve a mirar.

receive: no se puede tragar un efecto en silencio

Las acciones que un efecto devuelve al store no desaparecen: el TestStore las encola y exige que las reclames con receive. Reclamar un efecto es afirmar dos cosas a la vez: que llegó esa acción —identificada por su key path de caso— y qué estado dejó al procesarse.

@Test
func carga() async {
  let store = TestStore(initialState: Feature.State()) {
    Feature()
  } withDependencies: {
    $0.clienteAPI.cargar = { [.demo] }
  }
  await store.send(.aparecer) {
    $0.cargando = true
  }
  await store.receive(\.datosRecibidos) {
    $0.cargando = false
    $0.items = [.demo]
  }
}

Tras el send, el efecto corre y emite .datosRecibidos; el TestStore la retiene y espera a que la afirmes. Si terminaras el test sin recibirla, fallaría con un mensaje inequívoco: un efecto emitió una acción que nunca se afirmó. Esa es la exhaustividad de los efectos —hermana de la del estado—: nada de lo que vuelve puede pasar inadvertido. El test deja de ser una foto de un instante y se vuelve la transcripción íntegra de la conversación entre acciones y efectos.

El orden importa tanto como la presencia. Si una acción dispara dos efectos que devuelven .primero y .segundo, debes recibirlos en el orden en que llegan; reclamar .segundo antes que .primero falla igual que no reclamar ninguno. El TestStore no solo exige el qué —qué acciones volvieron— sino el cuándo relativo, porque la secuencia de los efectos es parte del comportamiento y, por tanto, parte de lo que una especificación honesta tiene que fijar.

Controlar el reloj y las dependencias

Un efecto que espera parece imposible de testear sin esperar de verdad. La salida es inyectar el tiempo como una dependencia más y congelarlo. TestClock no avanza solo: solo se mueve cuando tú se lo ordenas, lo que convierte un retardo real en un paso instantáneo y determinista.

@Test
func temporizador() async {
  let clock = TestClock()
  let store = TestStore(initialState: Temporizador.State()) {
    Temporizador()
  } withDependencies: {
    $0.continuousClock = clock
  }
  await store.send(.iniciar)
  await clock.advance(by: .seconds(1))
  await store.receive(\.tick) {
    $0.segundos = 1
  }
  await store.send(.parar)
}

clock.advance(by:) empuja el reloj un segundo y libera exactamente el tick que ese avance produce; lo recibes y afirmas el estado, sin un solo milisegundo de espera real. ImmediateClock va más lejos y colapsa toda espera a cero, útil cuando el cuándo no te importa y solo quieres que el efecto termine. Repara en el último send(.parar): si arrancaras el temporizador y no lo cancelaras, el TestStore fallaría al terminar porque detecta una tarea en vuelo. La exhaustividad también cubre el ciclo de vida: todo efecto que empieza tiene que acabar o cancelarse antes del final del test.

El diff como diálogo: deja que el test te diga qué hace

Hay una consecuencia liberadora de la aserción exhaustiva que casi nadie anticipa: no necesitas saber de antemano el estado exacto resultante. Puedes enviar la acción con una closure vacía o aproximada, ejecutar, y dejar que el TestStore te imprima un diff preciso entre lo que declaraste y lo que de verdad ocurrió.

await store.send(.incrementar) {
  // a propósito vacía: deja que el test te corrija
}
// El TestStore falla y muestra:
//   − $0.cuenta = 0
//   + $0.cuenta = 1

El fallo no es un castigo, es la respuesta a una pregunta. Lees el diff, copias la realidad —$0.cuenta = 1— dentro de la closure y el test pasa. Escribir el test se vuelve un diálogo: el reducer te dice qué hace y tú te limitas a ratificarlo. Este flujo invierte la tarea ingrata de predecir estados a ciegas y la convierte en leer y confirmar, y de paso deja la closure como documentación exacta de la transición: quien lea el test verá el cambio de estado real, no un vago comentario de que debería funcionar.

flowchart TD
T[TestStore] -->|send accion| RD[Reducer real corre y muta]
T -->|closure de asercion| EX[Estado esperado que declaras]
RD --> CMP[Comparacion campo a campo]
EX --> CMP
CMP --> V[Verde si todo coincide, rojo si algo difiere]
RD --> EF[Efecto emite accion de vuelta]
EF -->|receive| CMP
style T fill:#89b4fa,color:#11111b
style CMP fill:#f9e2af,color:#11111b