Model-based testing: que el modelo escriba los casos y la UI los sufra

Todo test escrito a mano comparte un sesgo con el código que verifica: lo escribió alguien que ya tenía un modelo mental de cómo funciona la aplicación, y ese modelo mental es justamente el que contiene los puntos ciegos que producen los defectos. Por eso las suites manuales cubren con generosidad el camino feliz y con negligencia la ruta de reintentar tras cancelar tras un fallo de red. El testing basado en modelos rompe ese sesgo por la vía estructural: no eliges tú los casos, los enumera un algoritmo sobre el grafo, y el algoritmo no tiene la costumbre de suponer que nadie pulsaría dos veces el botón de pagar. Tu trabajo se reduce a dos contratos honestos: decir cómo se reconoce cada estado en la pantalla real y cómo se provoca cada evento sobre ella. Todo lo demás —qué secuencias, en qué orden, cuántas— lo decide la topología.

Invertir quién elige los casos

La técnica descansa sobre una separación que conviene enunciar con precisión. Por un lado está el modelo: la máquina de estados que ya escribiste, que es la especificación del comportamiento. Por otro está el sistema bajo prueba: el componente real, con su árbol de nodos, sus peticiones y su navegador. El modelo genera recorridos; el sistema los ejecuta; una discrepancia entre lo que el modelo afirma y lo que la pantalla muestra es un defecto —en el código, o en el modelo, y averiguar cuál de los dos es el hallazgo más valioso de todos—.

import { createTestModel } from '@xstate/test'
import { caja } from './caja'

const modelo = createTestModel(caja)

describe('caja de pago', () => {
  for (const camino of modelo.getShortestPaths()) {
    it(camino.description, async () => {
      await camino.test(contratos)
    })
  }
})

Ese bucle es todo el andamiaje. Cada camino se convierte en un caso con nombre autogenerado —una descripción legible del recorrido— y la suite crece automáticamente cuando alguien añade un estado a la máquina. Esa última propiedad es la que cambia la economía del testing: un estado nuevo no exige escribir tests nuevos, los exige implementar, porque el generador ya está pidiendo que le digas cómo se verifica.

Los dos contratos

El modelo no sabe nada de tu interfaz, y esa ignorancia es deliberada. Le entregas dos diccionarios. El primero, indexado por estado, contiene aserciones que deben cumplirse cuando el recorrido pasa por ahí. El segundo, indexado por tipo de evento, contiene la acción que provoca ese evento sobre la aplicación real.

const contratos = {
  states: {
    vacio: () => {
      expect(pantalla.getByRole('button', { name: 'Pagar' })).toBeDisabled()
      expect(pantalla.queryByText(/error/i)).toBeNull()
    },
    listo: () => {
      expect(pantalla.getByRole('button', { name: 'Pagar' })).toBeEnabled()
    },
    pagando: () => {
      expect(pantalla.getByRole('progressbar')).toBeVisible()
    },
    fallo: () => {
      expect(pantalla.getByRole('alert')).toHaveTextContent(/no se pudo cobrar/i)
      expect(pantalla.getByRole('button', { name: 'Reintentar' })).toBeEnabled()
    },
  },
  events: {
    ANADIR: async () => {
      await usuario.click(pantalla.getByRole('button', { name: 'Anadir' }))
    },
    PAGAR: async () => {
      await usuario.click(pantalla.getByRole('button', { name: 'Pagar' }))
    },
    REINTENTAR: async () => {
      await usuario.click(pantalla.getByRole('button', { name: 'Reintentar' }))
    },
  },
}

Hay una regla de oro en el primer diccionario: las aserciones de estado deben mirar lo que el usuario percibe, no el estado interno. Comprobar que el actor está en pagando sería tautológico —el modelo ya lo sabe— y no verificaría nada. Comprobar que hay un indicador visible y que el botón está deshabilitado sí verifica algo real: que la traducción de estado a interfaz es correcta, que es exactamente el trozo de código que el modelo no puede garantizar por sí solo.

En el segundo diccionario la regla es de simetría: cada evento del alfabeto necesita su ejecutor, y un evento sin ejecutor no bloquea la generación, simplemente hace que esa arista no se recorra jamás. Conviene afirmarlo explícitamente para que un olvido no se convierta en un agujero silencioso de cobertura.

flowchart TB
M[maquina como especificacion] --> G[generador de caminos]
G --> C1[camino 1]
G --> C2[camino 2]
G --> C3[camino n]
C1 --> R[ejecutor]
C2 --> R
C3 --> R
R --> V[verificar estado en la pantalla]
R --> E[provocar evento sobre la pantalla]
V --> D[discrepancia igual a defecto]
style G fill:#89b4fa,color:#11111b
style D fill:#f38ba8,color:#11111b

Aislamiento, o la suite que se envenena a sí misma

Cada camino generado debe partir de un sistema idéntico. Si el caso anterior dejó un artículo en el carrito, una petición en vuelo o un token en almacenamiento local, el siguiente arranca desde un mundo que el modelo no contempla, y el fallo resultante apuntará al camino equivocado. La disciplina es la misma que en cualquier suite de integración, solo que aquí resulta obligatoria porque los casos son muchos y su orden lo decide un algoritmo.

beforeEach(async () => {
  servidorFalso.reiniciar()
  localStorage.clear()
  pantalla = montarCaja()          // render aislado del componente
})

afterEach(() => {
  pantalla.unmount()
})

Un síntoma inconfundible de aislamiento roto: los caminos cortos pasan y los largos fallan, o la suite pasa entera al ejecutarla en un orden y falla en otro. Cuando eso aparezca, no toques las aserciones; el defecto está en el montaje, no en el modelo. Y si al reiniciar entre casos la suite se vuelve intolerablemente lenta, la respuesta correcta no es compartir el estado sino reducir el número de caminos, que es el tema de la sección siguiente.

Dónde poner el freno

El número de caminos simples de un grafo con ciclos crece de forma explosiva, y una suite basada en modelos sin cotas puede pasar de treinta casos a tres mil por añadir un solo estado con dos aristas de vuelta. La gestión de ese riesgo es una decisión de ingeniería, no un ajuste técnico.

La última fila es la única que no sacrifica cobertura, y por eso es la más interesante. Si el grafo explota, casi siempre es porque dos preocupaciones independientes —el estado del carrito y el estado de la sesión, digamos— comparten una máquina y multiplican sus estados. Separarlas en regiones ortogonales convierte un producto cartesiano en una suma, y el número de caminos cae de golpe sin perder nada. La explosión combinatoria, aquí como en el capítulo de Harel, es un mensaje del diseño y no un límite de la herramienta.