Testear lo reactivo: efectos, suscripciones y limpieza

Todo lo anterior descansaba sobre una comodidad que ahora se acaba: una función pura entrega su resultado y con él entrega todo lo que hizo, de modo que comparar el valor devuelto agota la comprobación. Un efecto no funciona así. No devuelve nada, o devuelve una función de limpieza que tampoco es el resultado sino una promesa sobre el futuro. Su corrección no vive en un valor sino en tres preguntas distintas y sorprendentemente independientes: si ocurrió, cuántas veces ocurrió y si dejó de ocurrir cuando debía. Las dos primeras se testean con instrumentación y suelen escribirse; la tercera es la que casi nadie escribe, y es exactamente la que separa una aplicación que se degrada tras veinte minutos de uso de una que no. Una suscripción que sobrevive al componente que la creó no rompe nada de forma visible: sigue recibiendo notificaciones, sigue recalculando, sigue reteniendo en memoria un estado que ya nadie mira, y solo se manifiesta como una lentitud creciente que nadie sabe atribuir y como un error absurdo el día que intenta pintar sobre algo que ya no existe. Esta lección cierra el nivel enseñando a testear esa mitad impura del sistema: hacer observable lo que no retorna, hacer determinista lo que ocurre en el tiempo, y convertir la limpieza en una aserción explícita en lugar de una esperanza.

Hacer observable lo que no devuelve nada

El primer obstáculo es de observabilidad pura. Si un efecto no retorna, no hay nada que comparar, así que la única salida es instrumentar: colocar en el camino del efecto algo que registre su paso y afirmar después sobre ese registro. Hay tres formas de hacerlo y elegir mal es la causa habitual de tests reactivos frágiles.

Antes de elegir entre las tres conviene aplicar un filtro previo que ahorra la mitad del trabajo: preguntarse si lo que se quiere comprobar es de verdad el efecto o es la decisión que lo precede. Muchísimos tests de efectos existen solo porque alguien dejó una condición de negocio dentro del cuerpo del efecto. Si esa condición se extrae a una función pura que decide y devuelve una intención, la parte interesante vuelve al territorio barato de las cuatro lecciones anteriores y el efecto queda reducido a un ejecutor sin criterio, cuyo test es trivial. La regla es que el efecto debe ser tan tonto que testearlo aporte poco; cuando testear un efecto parece importante, suele ser porque contiene algo que no le pertenece.

El diario merece preferencia sobre el espía siempre que se pueda, porque afirma sobre la trayectoria y no sobre un instante. La pregunta más importante de un sistema reactivo casi nunca es si el efecto se ejecutó, sino cuántas veces se ejecutó: un efecto que corre tres veces donde debía correr una no falla ningún test de existencia y sin embargo triplica las peticiones al servidor, produce parpadeos y desordena respuestas.

test('el efecto corre una vez por cambio real, no por cada notificacion', () => {
  const diario: string[] = []
  const usuario = signal({ id: 1, nombre: 'Ada' })

  const parar = effect(() => {
    diario.push(`render:${usuario.get().id}`)
  })

  usuario.set({ id: 1, nombre: 'Ada Lovelace' }) // cambia nombre, no id
  usuario.set({ id: 2, nombre: 'Grace' })

  expect(diario).toEqual(['render:1', 'render:1', 'render:2'])
  parar()
})

El test anterior documenta con precisión quirúrgica una decisión de diseño que casi siempre queda implícita: el efecto se reejecuta al cambiar el nombre aunque solo lea el identificador, porque la dependencia se registró sobre el objeto entero y no sobre el campo. Si esa reejecución es indeseable, el diario acaba de convertir un problema de rendimiento invisible en una aserción concreta que alguien puede decidir arreglar.

Domesticar el tiempo

La segunda fuente de dolor es el tiempo. Una suite reactiva que espera de verdad —temporizadores reales, esperas por sondeo, pausas fijas de cien milisegundos— es lenta e intermitente, y la intermitencia es peor que la lentitud porque destruye la confianza en la señal. La solución no es esperar más, sino no esperar en absoluto: sustituir el reloj por uno falso que se avanza a mano y vaciar de forma explícita las colas donde el sistema encola trabajo diferido.

La distinción decisiva es entre esperar y avanzar. Esperar significa ceder el control al planificador real y confiar en que el trabajo pendiente se complete antes de la aserción, lo cual introduce una carrera entre el test y el sistema que se resuelve de forma distinta según la carga de la máquina; de ahí que estos tests fallen en la integración continua y pasen en el portátil. Avanzar significa mover el reloj de forma explícita hasta un instante elegido y ejecutar de forma síncrona todo lo que estuviera programado hasta él. Con la segunda estrategia el test no es más rápido por casualidad: es rápido y determinista porque nada queda librado al azar del planificador.

Hay que distinguir con cuidado tres colas distintas que suelen confundirse en una sola idea vaga de asincronía. La cola de macrotareas contiene los temporizadores y se avanza con el reloj falso. La cola de microtareas contiene las continuaciones de las promesas y se vacía cediendo el control una vez. Y la cola propia del sistema reactivo contiene los efectos programados por el batching, y se vacía con la primitiva que la librería exponga a tal efecto. Un test que solo avanza el reloj y olvida las microtareas queda a medio camino y falla de forma aleatoria según el orden de planificación.

test('el guardado diferido se dispara una sola vez tras la rafaga', async () => {
  vi.useFakeTimers()
  const guardar = vi.fn()
  const borrador = signal('')
  const parar = effect(() => guardarConRetardo(borrador.get(), guardar, 300))

  borrador.set('h')
  borrador.set('ho')
  borrador.set('hol')
  borrador.set('hola')

  await vi.advanceTimersByTimeAsync(299)
  expect(guardar).not.toHaveBeenCalled() // aun dentro de la ventana

  await vi.advanceTimersByTimeAsync(1)
  expect(guardar).toHaveBeenCalledTimes(1)
  expect(guardar).toHaveBeenCalledWith('hola')

  parar()
  vi.useRealTimers()
})

Repara en la aserción negativa antes del límite. Comprobar que algo todavía no ha ocurrido en el milisegundo anterior al umbral es lo que distingue un test de retardo diferido honesto de uno que pasaría igual sin ninguna lógica de retardo. Sin esa línea, el test solo dice que la función acaba llamándose, que es lo que haría también una implementación sin ventana ninguna.

El contrato de limpieza y la caza de fugas

Llegamos a la comprobación que da nombre al oficio y que casi ninguna suite incluye. Un efecto reactivo establece un contrato de dos direcciones: al crearse se suscribe a las fuentes que lee, y al destruirse debe darse de baja de todas ellas, cancelar sus temporizadores pendientes, abortar sus peticiones en vuelo y soltar sus referencias. La primera mitad se prueba sola porque si falla nada funciona. La segunda mitad no se prueba nunca porque si falla todo parece funcionar, y ese es exactamente el motivo por el que las fugas llegan a producción.

La técnica es sencilla en cuanto se acepta que hay que exponer un contador. Se mide el número de suscriptores vivos antes de crear el efecto, se crea, se comprueba que subió, se destruye y se comprueba que volvió exactamente al valor inicial. Ese ida y vuelta sobre un número entero detecta la inmensa mayoría de las fugas reales, incluidas las sutiles: la suscripción anidada que se registra dentro de otro efecto y no se cancela con él, la que se recrea en cada ejecución sin liberar la anterior, la que queda colgada de un valor derivado que ya nadie observa.

flowchart TD
A[Contar suscriptores vivos: base] --> B[Crear efecto o montar componente]
B --> C[Contar de nuevo: debe subir]
C --> D[Ejecutar la interaccion bajo prueba]
D --> E[Destruir efecto o desmontar]
E --> F[Contar por tercera vez]
F -->|vuelve a la base| OK[Sin fuga]
F -->|queda por encima| FUGA[Suscripcion huerfana]
FUGA --> G[Temporizador vivo, peticion sin abortar o arista sin borrar]
style A fill:#89b4fa,color:#11111b
style OK fill:#a6e3a1,color:#11111b
style FUGA fill:#f38ba8,color:#11111b

test('desmontar deja el grafo exactamente como estaba', () => {
  const base = contarSuscriptores(fuente)

  const parar = effect(() => derivado(fuente.get()))
  expect(contarSuscriptores(fuente)).toBe(base + 1)

  fuente.set(2)
  fuente.set(3) // que la reejecucion no acumule suscripciones

  parar()
  expect(contarSuscriptores(fuente)).toBe(base)
  expect(vi.getTimerCount()).toBe(0)
})

El mismo esquema se aplica sin cambios a un componente completo: se cuenta antes de montar, se monta, se interactúa, se desmonta y se vuelve a contar. Y admite una generalización que conviene adoptar como norma de equipo: en lugar de escribir la comprobación caso a caso, se instala en el gancho de limpieza global una aserción que verifique que al terminar cada test no quedan temporizadores vivos ni suscriptores por encima de la línea base. Esa única regla, escrita una vez, convierte toda la suite existente en un detector de fugas sin tocar ni un test.

La penúltima línea del ejemplo cubre el error más frecuente de todos: el efecto que en cada reejecución vuelve a suscribirse sin haber soltado la suscripción anterior. Sin las dos escrituras intermedias, el test pasaría igualmente con esa implementación defectuosa, porque el efecto solo se habría ejecutado una vez. Provocar varias reejecuciones antes de destruir es lo que convierte la aserción en una prueba de verdad.