Estrategia de testing: qué exigir y dónde aflojar

Tener dos regímenes de severidad convierte el testing en un problema de asignación: ya no se trata de si testear, sino de repartir un recurso escaso —la rigidez que impones a tu propio código— entre los sitios donde compra seguridad y los sitios donde solo compra fricción. Casi todas las suites que envejecen mal cometen el mismo error de asignación, y no es el que la gente supone: no fallan por testear poco, fallan por testear todo con la misma severidad, gastando en la coreografía de un flujo de siete pantallas el mismo rigor que en la regla de negocio que decide si un pago se acepta. Esta lección propone un criterio explícito para repartir, un reparto concreto por tipo de código y una forma honesta de saber si la suite protege algo o solo lo parece.

Dos ejes deciden la severidad

El primer eje es la previsibilidad: si eres capaz de derivar el estado resultante desde el modelo de dominio antes de ejecutar el test, la aserción exhaustiva es conocimiento y cada línea es una predicción arriesgada. Si el único modo de saber qué queda es ejecutar y copiar, la aserción exhaustiva es una copia y no puede falsar nada. Este eje ordena por tamaño del sujeto, pero no exactamente: hay reducers pequeños e impredecibles —los que orquestan tres dependencias con reintentos— y árboles medianos perfectamente predecibles.

El segundo eje es el carácter publicado de lo que verificas. Un caso de delegate, la forma del State inicial, el nombre de una acción que otra feature envía: todo eso es interfaz, y congelar una interfaz es exactamente para lo que sirven los tests. Un caso internal que existe porque el autor prefirió partir el trabajo en dos pasos es encapsulación, y congelarla es cerrarse la puerta a mejorarla. La distinción no es de visibilidad en Swift sino de compromiso: publicado es lo que otro módulo, otra feature o un futuro tú tendrá derecho a asumir.

flowchart TD
Q[Que pregunta responde este test] --> U[Como se comporta esta maquina de estados]
Q --> J[Que ocurre cuando el usuario recorre este camino]
U --> P[Puedes predecir el estado resultante sin ejecutar]
P -->|si| E[Exhaustivo campo a campo]
P -->|no| M[Simplifica el modelo antes de testear]
J --> L[No exhaustivo con asercion final]
L --> C[Afirma contratos publicados y puntos de contacto]
E --> S[Rompe cuando cambia el comportamiento]
C --> S
style E fill:#a6e3a1,color:#11111b
style C fill:#89b4fa,color:#11111b
style M fill:#f9e2af,color:#11111b

El diagrama esconde una afirmación fuerte que conviene sacar a la luz: cuando un reducer no es predecible, la respuesta correcta no es bajar la severidad del test, es arreglar el reducer. Un estado del que no puedes anticipar la transición es un estado con demasiadas responsabilidades, con invariantes implícitas o con dependencias que hacen más de lo que su nombre promete. El test exhaustivo, aquí, funciona como un detector de complejidad accidental, y renunciar a él antes de escuchar lo que dice es silenciar el instrumento en vez de atender la lectura.

El reparto, por tipo de código

La fila del delegate merece una lectura despacio porque es la más útil y la que más gente pasa por alto. En un test de integración laxo, recibir explícitamente la acción de delegación no contradice la laxitud: es una excepción deliberada que fija justo el punto donde dos features se comprometen. Todo lo demás en ese test puede aflojarse; ese receive, no. Y la fila de la telemetría dice lo contrario por el mismo motivo: si tus tests de flujo se rompen cada vez que alguien añade un evento de analítica, no es que el test sea estricto, es que la telemetría está cableada donde no debe —probablemente en el padre en lugar de en un reducer propio compuesto aparte.

// Exhaustivo: una rama de negocio, predecible y con consecuencias
@Test
func rechazaPagoConSaldoInsuficiente() async {
  let store = TestStore(initialState: Pago.State(saldo: 10, importe: 25)) {
    Pago()
  }
  await store.send(\.view.confirmarPulsado) {
    $0.error = .saldoInsuficiente
    $0.procesando = false
  }
}

// No exhaustivo: un camino de usuario, con la garantía al final
@Test
func altaCompletaDejaSesionIniciada() async {
  let store = TestStore(initialState: Alta.State()) {
    Alta()
  } withDependencies: {
    $0.cuentas.crear = { _ in .demo }
  }
  store.exhaustivity = .off

  await store.send(\.datos.correoEscrito, "a@b.c")
  await store.send(\.datos.continuarPulsado)
  await store.send(\.verificacion.codigoEscrito, "123456")
  await store.send(\.verificacion.continuarPulsado)
  await store.receive(\.verificacion.delegate.verificado)

  store.assert { $0.sesion = .demo }
}

Los dos tests miden cosas incomparables y por eso se escriben distintos. El primero afirma una regla: con saldo insuficiente no se cobra. El segundo afirma un desenlace: quien completa el alta acaba con sesión. Poner el primero en modo laxo sería tirar la mitad de su valor, porque la mitad de la regla está en el procesando que también hay que fijar; poner el segundo en modo exhaustivo lo haría cuatro veces más largo sin añadir una sola garantía nueva.

Cobertura, mutación y tests que nunca fallan

El porcentaje de cobertura mide qué líneas se ejecutaron, no qué comportamientos se verificaron, y con el modo no exhaustivo esa brecha se vuelve enorme: un test que recorre siete pantallas sin afirmar nada ilumina cientos de líneas y garantiza cero. Usar la cobertura como objetivo, en una suite que mezcla regímenes, no es solo poco informativo: premia justamente los tests que menos protegen.

// Antes: la guarda que impide cobrar dos veces
guard !state.procesando else { return .none }
state.procesando = true

// Mutación deliberada: si la suite sigue verde, esa guarda no está protegida
// guard !state.procesando else { return .none }
state.procesando = true

La pregunta que sí discrimina es la de mutación: si estropeo esta línea a propósito, ¿se pone algo rojo? Invierte una condición, borra una asignación, comenta el return de un efecto. Si la suite entera sigue verde, esa línea no está protegida, por mucho que la cobertura la marque en color. Aplicada a mano sobre las diez o quince líneas que de verdad importan de una feature, esta prueba cuesta veinte minutos y produce un diagnóstico infinitamente más honesto que cualquier informe automático.

El presupuesto de la suite

Una prueba es código que alguien mantiene, y su coste no se paga al escribirla sino en cada refactor posterior. Ese coste es proporcional a cuántas afirmaciones hace sobre detalles que van a cambiar, y su beneficio es proporcional a la probabilidad de que detecte un error real multiplicada por el daño que ese error causaría. La consecuencia práctica es que hay tests con beneficio neto negativo, y que borrarlos es una mejora, no una rendición.

Tres criterios ayudan a decidir en la práctica. El primero es la volatilidad: sobre código que cambia cada semana, la rigidez se paga cada semana; ahí conviene afirmar solo el contrato y dejar libre el interior. El segundo es el daño: un error en el cálculo de un importe cuesta dinero y confianza, uno en el orden de dos animaciones cuesta una queja; el rigor debe seguir esa curva y no la del entusiasmo. El tercero es la detectabilidad por otras vías: si un error se manifiesta al abrir la aplicación en cualquier previsualización, invertir en un test caro para él es duplicar una defensa barata. Bajo estos tres criterios, la forma canónica de una suite TCA sana suele ser una base ancha de tests exhaustivos y cortos sobre reducers hoja, una capa fina de tests de integración laxos con una aserción cada uno, y un puñado casi anecdótico de comprobaciones sobre la vista, que es lo que verá la lección siguiente.