Testear cancelación y efectos de larga vida

Un efecto que carga datos y termina es fácil de testear: se dispara, vuelve una acción, se afirma el estado. Un efecto que no termina —un temporizador, una suscripción a notificaciones, un stream de posiciones— plantea preguntas de otra naturaleza, y son justo las que más bugs esconden en producción: si la pantalla desaparece, ¿el bucle muere o sigue vivo consumiendo batería? Si la cancelación llega mientras el efecto duerme, ¿se limpia el recurso? Si el stream emite tres eventos, ¿llegan los tres, en orden y una sola vez? Ninguna de esas preguntas se contesta observando lo que ocurre, porque todas hablan de lo que debe dejar de ocurrir. Y ahí la combinación de reloj controlado y TestStore exhaustivo da su mejor resultado, porque entre ambos convierten la ausencia —el silencio después de cancelar, el bucle que ya no está— en algo que la máquina verifica.

El detector de fugas

Cuando un test termina con un efecto todavía en marcha, el TestStore falla. La primera reacción de casi todo el mundo es tratarlo como una molestia del framework y buscar la manera de silenciarlo; la lectura correcta es la contraria, porque ese fallo describe una situación que en producción tiene nombre propio.

await store.send(.aparecer)          // arranca un temporizador
// El test acaba aqui: el TestStore falla porque un efecto sigue vivo

Piensa qué representa ese efecto huérfano fuera del test. Un bucle que sigue latiendo después de que la pantalla se haya ido, un observador que continúa reaccionando a notificaciones de una feature que ya no existe, una tarea que mantiene vivo por retención todo el grafo de objetos de una pantalla cerrada. Son fugas de recursos con síntomas clásicos —batería, memoria, actualizaciones de estado sobre una vista invisible— y son especialmente difíciles de detectar a mano, porque no producen ningún error visible: simplemente el sistema se degrada. El TestStore las convierte en un fallo determinista y reproducible antes de que salgan del portátil.

De ahí se sigue una consecuencia de diseño: todo efecto de larga vida necesita una historia de terminación explícita, y el test es donde esa historia queda escrita. O bien el reducer lo cancela ante una acción concreta, o bien el efecto termina solo cuando su fuente se agota. Un efecto sin historia de terminación es un defecto, no una comodidad.

Demostrar el silencio

El patrón para verificar una cancelación tiene tres movimientos y el tercero es el que casi nadie escribe.

@Test
func alDesaparecerElTemporizadorSeDetiene() async {
  let clock = TestClock()
  let store = TestStore(initialState: Panel.State()) {
    Panel()
  } withDependencies: {
    $0.continuousClock = clock
  }

  await store.send(.aparecer)
  await clock.advance(by: .seconds(1))
  await store.receive(\.tick) { $0.segundos = 1 }

  await store.send(.desaparecer)
  await clock.advance(by: .seconds(5))   // el silencio se afirma no reclamando nada
}

El primer movimiento establece que el efecto estaba vivo —sin ese latido inicial, el test pasaría también con un reducer que nunca arrancó nada, y estaría probando el vacío—. El segundo cancela. El tercero es el avance de cinco segundos que no va seguido de ningún receive, y es una aserción de pleno derecho aunque no tenga forma de tal: si el temporizador siguiera vivo, ese avance produciría cinco latidos, ninguno estaría reclamado y el test fallaría al terminar. La exhaustividad del TestStore es lo que da sentido a la línea; en un store permisivo, ese avance no diría nada.

Conviene entender también dónde muere exactamente el efecto. La cancelación se hace efectiva en el punto de suspensión, es decir, dentro del sueño del reloj: la llamada lanza el error de cancelación, la closure se desenrolla y TCA descarta ese error sin convertirlo en ninguna acción. Por eso el silencio es total y no aparece un fallo espurio. Y por eso mismo un efecto que hiciera trabajo síncrono largo sin ningún punto de suspensión sería incancelable en la práctica: la cancelación cooperativa necesita que alguien coopere.

sequenceDiagram
participant T as Test
participant S as Store
participant E as Efecto de larga vida
T->>S: send aparecer
S->>E: arranca y se suscribe
T->>S: avance del reloj
E-->>S: tick
S-->>T: receive reclamado
T->>S: send desaparecer
S->>E: cancelacion por identidad
Note over E: el bucle termina y libera el recurso
T->>S: avance del reloj
Note over S: ninguna accion llega, el test acaba limpio

Un stream con la continuación en la mano

Los efectos de larga vida más interesantes no son temporizadores sino suscripciones: eventos del sistema, mensajes de un socket, cambios de una base de datos. La dependencia devuelve una secuencia asíncrona y el efecto la consume en un bucle.

@DependencyClient
struct ClienteEventos {
  var eventos: @Sendable () -> AsyncStream<Evento> = { .never }
}

case .aparecer:
  return .run { send in
    for await evento in cliente.eventos() {
      await send(.evento(evento))
    }
  }
  .cancellable(id: CancelID.suscripcion)

Para testearlo, el truco consiste en fabricar el stream en el propio test y quedarse con su continuación: la dependencia entrega el extremo de lectura y tú conservas el de escritura, con lo que pasas a decidir qué se emite y cuándo.

@Test
func elStreamEntregaSusEventosEnOrden() async {
  let (stream, continuacion) = AsyncStream.makeStream(of: Evento.self)
  let store = TestStore(initialState: Panel.State()) {
    Panel()
  } withDependencies: {
    $0.clienteEventos.eventos = { stream }
  }

  await store.send(.aparecer)

  continuacion.yield(.conectado)
  await store.receive(\.evento.conectado) { $0.estado = .conectado }

  continuacion.yield(.mensaje("hola"))
  await store.receive(\.evento.mensaje) { $0.mensajes = ["hola"] }

  continuacion.finish()
  await store.finish()
}

El test lee como un guion y verifica más de lo que declara: que cada emisión produce exactamente una acción, que el orden se conserva y que ninguna se pierde ni se duplica. La llamada final a finish sobre la continuación agota la fuente, el bucle del efecto sale por sí solo y store.finish() espera a que esa terminación se complete antes de dar el test por bueno. Sin esas dos líneas volveríamos al fallo por efecto vivo, y con razón: un stream que nadie cierra es un stream que sigue abierto.

Nota la asimetría entre las dos formas de terminar, porque es la que decide el diseño del reducer. Un stream que se agota por su cuenta comunica se acabó la fuente; una cancelación comunica ya no me interesa. La primera puede requerir que el reducer reaccione —reconectar, marcar la sesión como caída—; la segunda debe ser silenciosa. Si tu efecto no distingue ambos casos, tarde o temprano intentará reconectar justo cuando la pantalla se está cerrando.

Terminación observable y limpieza

Queda la pregunta más fina: no si el bucle terminó, sino si el recurso que sostenía se liberó. El extremo de escritura de un stream permite observarlo, porque su terminación notifica la causa.

let limpiezas = LockIsolated(0)
continuacion.onTermination = { _ in limpiezas.withValue { $0 += 1 } }
// ...
await store.send(.desaparecer)
#expect(limpiezas.value == 1)

Con eso el test ya no afirma solo que dejaron de llegar acciones, sino que la cancelación llegó hasta el productor y este cerró lo que tuviera abierto: el socket, el observador, el fichero. Es la diferencia entre el consumidor dejó de escuchar y la conexión se cerró, y en un cliente de red esa diferencia se paga en conexiones colgadas.