La transición como función pura: testear sin ejecutar la máquina

Toda la disciplina de testing de máquinas de estado descansa sobre un hecho que ya conoces pero cuyas consecuencias prácticas casi nunca se explotan: la transición es una función pura. Dado un snapshot y un evento, el snapshot siguiente está completamente determinado, y calcularlo no requiere un intérprete, ni un buzón, ni un reloj, ni una promesa, ni un componente montado. Eso significa que la mayor parte de la lógica de tu aplicación —la que decide qué es legal, qué es imposible y qué datos se actualizan— es verificable con la misma tecnología con la que se verifica una función de suma: entradas conocidas, salida esperada, cero infraestructura. Empezar por aquí no es empezar por lo fácil; es empezar por donde vive la mayoría de los defectos de diseño, y hacerlo con pruebas que corren en microsegundos y no parpadean jamás.

El par que devuelve estado y acciones

XState expone el corazón determinista de la máquina como dos funciones libres. initialTransition recibe la lógica y devuelve el punto de partida; transition recibe la lógica, un snapshot y un evento, y devuelve el siguiente. Ambas retornan una tupla: primero el snapshot, después la lista de acciones que un intérprete debería ejecutar. No las ejecuta. Esa negativa es lo que mantiene el cálculo puro y lo que te permite afirmar sobre los efectos sin provocarlos.

import { initialTransition, transition } from 'xstate'
import { formulario } from './formulario'

const [s0] = initialTransition(formulario)
const [s1, acciones] = transition(formulario, s0, {
  type: 'ESCRIBIR',
  campo: 'correo',
  valor: 'ana@ejemplo.com',
})

expect(s0.value).toBe('vacio')
expect(s1.value).toBe('editando')
expect(s1.context.correo).toBe('ana@ejemplo.com')
expect(acciones).toHaveLength(0)

La tercera aserción es la más interesante y la que casi nadie escribe: comprobar que una transición no programó ningún efecto. Un test que solo mira el estado destino da por buena una transición que además dispara una petición indebida; mirar la lista de acciones convierte los efectos en parte del contrato verificado en lugar de dejarlos como daño colateral invisible.

Conviene no confundir este par con su hermano impuro. getNextSnapshot y getInitialSnapshot existen para el caso en que quieras el snapshot final con las acciones ya aplicadas, y por eso ejecutan lo que encuentran. Sirven para exploraciones rápidas y para el recorrido de grafos, pero no son la herramienta de un test unitario que aspira a no tocar el mundo.

Dos aserciones que van siempre juntas

El error más común al testear una máquina es afirmar únicamente sobre snapshot.value. Una máquina bien diseñada reparte su significado entre dos planos: el estado finito, que dice en qué régimen está, y el context, que dice con qué datos. Verificar solo uno deja la mitad del contrato sin cubrir, y suele ser precisamente la mitad donde se esconden los defectos sutiles: la transición correcta que acumula mal, el assign que pisa un campo que debía conservarse, el contador que se reinicia una vez de más.

const eventos = [
  { type: 'ESCRIBIR', campo: 'correo', valor: 'a@b.c' },
  { type: 'ENVIAR' },
  { type: 'FALLO', motivo: 'red' },
  { type: 'REINTENTAR' },
] as const

const final = eventos.reduce(
  (snap, ev) => transition(formulario, snap, ev)[0],
  initialTransition(formulario)[0],
)

expect(final.value).toBe('enviando')
expect(final.context.intentos).toBe(2)
expect(final.context.correo).toBe('a@b.c')   // sobrevivio al fallo

Ese reduce no es un truco de estilo: es la afirmación literal de que la máquina es un plegado sobre la secuencia de eventos. Escribir así los tests hace evidente la propiedad que los habilita —la historia completa de un actor está determinada por su lista de eventos— y produce, gratis, una forma cómoda de describir escenarios largos sin ceremonia. Cuando un caso falla, el diagnóstico es inmediato porque la secuencia está a la vista, en orden, sin await que la interrumpa.

Empezar en medio y tabular los casos

Reconstruir desde el estado inicial cada escenario es correcto pero costoso de leer cuando el recorrido es largo. machine.resolveState fabrica un snapshot válido a partir de un valor de estado y un context parcial, resolviendo por ti los estados compuestos, los paralelos y los valores por defecto. Es el equivalente a colocar la pieza en mitad del tablero sin haber jugado la partida.

const enviando = formulario.resolveState({
  value: 'enviando',
  context: { correo: 'a@b.c', intentos: 1 },
})

const [tras] = transition(formulario, enviando, { type: 'FALLO', motivo: 'red' })
expect(tras.value).toBe('error')
expect(tras.context.intentos).toBe(1)

Con ese punto de entrada, la tabla de transiciones deja de ser documentación y se convierte en el propio conjunto de casos. La correspondencia es exacta: cada fila de la tabla es una llamada a transition, y una tabla completa es una suite completa.

const casos = [
  ['vacio', { type: 'ESCRIBIR', campo: 'correo', valor: 'x' }, 'editando'],
  ['editando', { type: 'ENVIAR' }, 'enviando'],
  ['enviando', { type: 'EXITO' }, 'hecho'],
  ['enviando', { type: 'FALLO', motivo: 'red' }, 'error'],
  ['error', { type: 'REINTENTAR' }, 'enviando'],
  ['hecho', { type: 'ENVIAR' }, 'hecho'],
] as const

test.each(casos)('%s con %o va a %s', (origen, evento, destino) => {
  const desde = formulario.resolveState({ value: origen })
  expect(transition(formulario, desde, evento)[0].value).toBe(destino)
})

flowchart LR
S[snapshot n] --> F[funcion de transicion]
E[evento] --> F
F --> S2[snapshot n mas 1]
F --> A[lista de acciones sin ejecutar]
style F fill:#89b4fa,color:#11111b
style A fill:#f9e2af,color:#11111b

Lo que esta prueba no puede ver

Ser explícito sobre los límites de una técnica es parte de dominarla. La transición pura no ve nada que dependa del tiempo real, porque no hay reloj; no ve lo que ocurre dentro de un actor invocado, porque nadie lo arranca; no ve el orden de ejecución de las acciones ni sus efectos, porque las devuelve sin correrlas; y no ve si tu interfaz refleja el estado, porque no hay interfaz.

Esa repartición sugiere la pirámide de este nivel entero: la mayoría de los casos en transiciones puras, unos pocos con el actor arrancado y el reloj bajo control, y una capa fina —generada, no escrita a mano— contra la interfaz real. Las tres lecciones siguientes recorren exactamente esos escalones.