Testear reducers: el test más barato y más valioso

Todo el aparato de Redux —el store, el middleware, los selectores, los thunks— existe para proteger y orquestar una única función diminuta: el reducer. Y esa función es pura. No lee un reloj, no toca la red, no consulta el DOM, no depende de en qué orden la llames ni de cuántas veces. Dale el mismo estado y la misma acción y devolverá siempre el mismo resultado. Esa propiedad, que parecía una restricción incómoda cuando la aprendiste, es en realidad el regalo más grande que Redux le hace a tu suite de tests: el corazón de tu lógica de dominio se puede verificar sin arrancar nada. No hay navegador, no hay servidor, no hay ciclo de vida de componente, no hay temporizadores, no hay dobles de prueba. Hay una llamada a una función y una comparación. Por eso los tests de reducers son, en relación coste-valor, los mejores tests que escribirás en tu vida, y por eso son el suelo sobre el que se apoya todo lo demás en este nivel.

La pureza como propiedad de testabilidad

Un reducer tiene la firma más simple que existe en una arquitectura de aplicación: recibe un estado y una acción, devuelve un estado. Ni siquiera necesita saber que hay un store, ni que hay React, ni que hay una red. Es una función de transición, en el sentido estricto que un teórico de autómatas le daría a esa palabra: un morfismo del producto de estados por alfabeto de entrada al conjunto de estados.

Esa naturaleza tiene una consecuencia práctica brutal en el coste del test. Testear una unidad de lógica normalmente exige construir su contexto: instanciar dependencias, inyectar dobles, controlar el tiempo, esperar promesas, limpiar entre casos. Cada una de esas necesidades introduce acoplamiento, lentitud y falsos positivos. Un reducer no exige nada de eso. El contexto completo de un test de reducer son dos valores que tú construyes a mano y un tercero que comparas.

flowchart LR
A[estado previo] --> C[reducer]
B[accion] --> C
C --> D[estado siguiente]
D --> E[afirmacion de igualdad]
style C fill:#89b4fa,color:#11111b
style E fill:#a6e3a1,color:#11111b

Hay un segundo regalo, menos obvio y más profundo. Un store real no aplica un reducer una vez, sino que pliega una secuencia entera de acciones sobre un estado inicial: la historia de la aplicación es un fold sobre el flujo de acciones, y el reducer es la función de paso de ese pliegue. La teoría del pliegue dice que si la función de paso es correcta para cualquier par de estado y acción, entonces el pliegue es correcto para cualquier secuencia, por inducción sobre su longitud. Traducido a tu suite: probando exhaustivamente el paso, obtienes garantías sobre historias que nunca escribiste como test. Ningún otro tipo de test de tu aplicación te da ese apalancamiento.

La forma canónica y qué afirmar

El test se escribe siempre igual, y esa monotonía es una virtud: construyes el estado previo, aplicas la acción, comparas con el estado esperado. Con createSlice de Redux Toolkit exportas el reducer y lo llamas directamente, sin store; las acciones se construyen con los propios action creators generados, de modo que el test se rompe si cambia el tipo de la acción.

import { describe, it, expect } from 'vitest'
import reducer, { anadido, alternado, eliminado } from './todosSlice'
import type { TodosState } from './todosSlice'

const base: TodosState = {
  entidades: { a1: { id: 'a1', texto: 'leer', hecho: false } },
  ids: ['a1'],
  filtro: 'todos',
}

describe('todosSlice', () => {
  it('devuelve el estado inicial cuando no hay estado previo', () => {
    expect(reducer(undefined, { type: 'accion/desconocida' })).toEqual({
      entidades: {}, ids: [], filtro: 'todos',
    })
  })

  it('anade un todo al final y no toca los existentes', () => {
    const siguiente = reducer(base, anadido({ id: 'b2', texto: 'dormir' }))
    expect(siguiente.ids).toEqual(['a1', 'b2'])
    expect(siguiente.entidades.a1).toBe(base.entidades.a1) // reparto estructural
  })

  it('ignora acciones que no le pertenecen', () => {
    expect(reducer(base, { type: 'otroSlice/algo' })).toBe(base)
  })
})

Fíjate en el tercer caso: comparamos con toBe, no con toEqual. Afirmar identidad referencial no es un capricho de purista; es verificar el contrato de reparto estructural del que depende toda la reactividad de la capa de lectura. Un reducer que clona ramas que no tocó produce estados iguales en valor pero distintos en identidad, y esa diferencia invisible en un toEqual es exactamente la que dispara renders inútiles en producción. Los tests de reducer son el único sitio barato donde puedes cazar esa regresión.

Sobre los casos frontera conviene ser explícito, porque son los que la gente omite y los que producen los incidentes. Eliminar una entidad que no existe, alternar un identificador ya borrado, recibir dos veces la misma acción por un doble clic o un reintento: en producción todos ocurren. Un reducer robusto los absorbe devolviendo el estado sin cambios, y ese comportamiento merece un test tanto como el camino feliz, porque es una decisión de diseño y no un accidente.

Una advertencia sobre la granularidad de las afirmaciones. Es tentador comparar el estado siguiente entero con un literal completo, y en slices pequeños funciona bien; en slices grandes convierte cada test en un espejo de la estructura y lo rompe cualquier campo nuevo. La alternativa razonable es afirmar sobre las ramas que la acción debía tocar y añadir una única afirmación de que las demás quedaron idénticas por referencia. Así el test describe la transición —lo que cambia y lo que no— en lugar de fotografiar el estado, que es justo la distinción que la última lección del nivel convertirá en criterio general.

Estado inicial, fixtures y propiedades

Dos detalles operativos elevan mucho la calidad de la suite. El primero: prueba el estado inicial pasando undefined como estado previo con una acción desconocida, tal y como hace el store al arrancar. Ese caso protege el contrato de arranque y detecta el olvido clásico de añadir un campo nuevo al initialState. Con Redux Toolkit tienes además slice.getInitialState(), que te evita duplicar el literal en el test.

El segundo: usa el propio reducer para construir fixtures complejos en lugar de escribir a mano estados profundos. Encadenar acciones desde el estado inicial produce un fixture que por construcción es alcanzable, mientras que un literal escrito a mano puede describir un estado que tu aplicación nunca podría alcanzar, y probar sobre estados imposibles es gastar esfuerzo en verificar ficción.

import { describe, it, expect } from 'vitest'
import * as fc from 'fast-check'
import reducer, { anadido, eliminado } from './todosSlice'
import slice from './todosSlice'

const plegar = (acciones: ReturnType<typeof anadido>[]) =>
  acciones.reduce(reducer, slice.getInitialState())

it('los ids nunca contienen duplicados', () => {
  fc.assert(
    fc.property(fc.array(fc.uuid()), (ids) => {
      const estado = plegar(ids.map((id) => anadido({ id, texto: 't' })))
      return new Set(estado.ids).size === estado.ids.length
    }),
  )
})

Ese salto —de casos ejemplares a propiedades cuantificadas sobre todas las secuencias posibles— es el que la pureza hace posible y trivial. Con fast-check generas historias arbitrarias de acciones y afirmas invariantes que deben valer al final de cualquiera de ellas: que ids y entidades estén sincronizados, que un contador nunca sea negativo, que aplicar dos veces una acción idempotente dé el mismo resultado que aplicarla una. Es verificación cercana a la formal a coste de test unitario, y solo es viable porque no hay efectos que simular.