Cómo un arnés de paridad demuestra una reescritura

Una reescritura está lista cuando se comporta como el sistema al que sustituye con las entradas que importan. Una arquitectura limpia, las pruebas unitarias superadas y unas pantallas conocidas no demuestran que el sistema nuevo contabilice los mismos totales de factura, elija la misma base fiscal o rechace el mismo ajuste mal formado. Un arnés de paridad sí lo demuestra. Envía la misma solicitud grabada a ambos sistemas, captura todos los resultados observables, normaliza solo los campos que pueden variar y produce una diferencia que una persona responsable puede explicar.

Parece una prueba de regresión normal hasta que entran en juego el dinero, las fechas, el estado y los efectos secundarios. Entonces falla la comparación fácil. La aplicación antigua puede leer el reloj a mitad de un cálculo, depender del orden de los registros, redondear después de cada línea, reutilizar un tipo de cambio obsoleto o escribir cinco filas antes de devolver una respuesta. Algunos de esos comportamientos son requisitos. Otros son accidentes de los que ahora dependen los usuarios. Otros son errores. El arnés debe distinguirlos sin ocultar pruebas incómodas.

Uso la paridad como argumento de aceptación, no como porcentaje de un panel. El argumento tiene cuatro partes: la entrada reproducida representa la producción, ambas ejecuciones empiezan desde un estado equivalente, la política de comparación es explícita y cada diferencia aceptada tiene responsable y motivo. Si alguna parte es ambigua, un resultado verde significa muy poco.

En qué se diferencia la paridad de una regresión normal

Un arnés de paridad compara dos implementaciones del mismo comportamiento. Una batería de regresión compara una implementación con expectativas escritas por personas. Esa distinción cambia lo que cada prueba puede descubrir. Una prueba unitaria puede confirmar que una función de intereses reescrita coincide con una fórmula elegida para la prueba. No puede decir que el sistema antiguo trunca el tipo diario antes de capitalizar, salvo que alguien ya conociera esa peculiaridad y la codificara. Reproducir la misma cuenta en ambos sistemas revela la diferencia de inmediato.

El sistema antiguo actúa como especificación ejecutable, pero no es infalible. Tratarlo como oráculo convierte su salida en una prueba, no en la verdad. El arnés debe informar que el sistema heredado devolvió 104,17 y la reescritura 104,18. Un responsable de producto, controlador financiero o propietario de dominio designado decide si ese céntimo pertenece al contrato o a un defecto. La maquinaria de prueba no debe tomar esa decisión de política redondeando en silencio los dos valores hasta que coincidan.

Las pruebas de regresión siguen siendo necesarias. Aíslan reglas, cubren límites sintéticos y son lo bastante rápidas para cada commit. La paridad cubre combinaciones que nadie recordó describir: una línea de valor cero después de una nota de abono, un cliente con dos calendarios de facturación o un programa RPG que trata los espacios de forma distinta a los ceros. Conserve ambas. Cuando se resuelva una diferencia, convierta la decisión en una prueba de regresión específica para que el equipo no tenga que redescubrirla en otra reproducción masiva.

El arnés también compara más que la respuesta visible. En una transacción, el contrato observable puede incluir mutaciones de base de datos, archivos emitidos, mensajes de cola, asientos contables, códigos de estado, categorías de error y orden. Si el reemplazo devuelve el total correcto pero lo contabiliza en el periodo equivocado, la paridad solo de respuesta da una aprobación peligrosa. Defina el límite de observación antes de grabar tráfico e incluya todos los efectos que pueda ver otro sistema o una persona.

El tráfico grabado necesita un contrato de reproducción

Una grabación útil contiene información suficiente para reproducir la intención sin copiar un montón descontrolado de registros. Los registros de acceso sin tratar rara vez sirven. Pueden omitir cuerpos de solicitud, identidad autenticada, estado de sesión, cabeceras que seleccionan una regla empresarial o la secuencia que creó el estado actual de la base de datos. También pueden incluir secretos que jamás deben entrar en un almacén de pruebas.

Use un sobre de reproducción versionado. El sobre indica qué llegó, qué contexto afectó al comportamiento, qué punto de control de estado espera el caso y qué salidas inspeccionará el arnés. Una forma práctica es esta:

{
  "case_id": "close-004812",
  "captured_at": "2026-01-31T23:58:42Z",
  "operation": "POST /accounts/close",
  "identity_ref": "role:month_end_operator",
  "state_checkpoint": "ledger-2026-01-31-r7",
  "request": {"account_id": "A1842", "period": "2026-01"},
  "observe": ["response", "ledger_entries", "outbox"]
}

Guarde referencias a identidades y secretos, nunca credenciales activas. Sustituya los campos personales solo mediante una asignación determinista, porque el anonimizado aleatorio puede destruir uniones y significado empresarial. Si el cliente 842 aparece en una solicitud, una fila contable y una tabla de direcciones, el fixture saneado debe mantener conectadas esas referencias. Conserve longitudes y clases de caracteres cuando la validación dependa de ellas.

El muestreo merece una política escrita. Una porción aleatoria de solicitudes comunes aporta volumen, pero suele omitir los casos raros con riesgo financiero u operativo. Combine una muestra de producción con estratos deliberados: tipo de operación, éxito y fracaso, importes altos y nulos, límites de calendario, codificaciones inusuales, trabajos largos y cada rama vinculada al dinero o los permisos. Grabe las sesiones de varios pasos como casos ordenados cuando las llamadas posteriores dependan de las anteriores.

Mantenga inmutable la captura original. Derive de ella fixtures saneados y reproducibles con transformaciones versionadas, y registre la versión de la transformación en cada ejecución. De lo contrario, un cambio en el depurador puede alterar la entrada mientras el equipo cree que está evaluando un programa modificado. El acceso a las capturas debe ser limitado, su retención finita y un caso fallido debe mostrar identificadores mediante diagnósticos controlados en lugar de volcar registros completos en los logs de CI.

Un estado inicial equivalente forma parte de la prueba

La misma solicitud contra datos distintos no demuestra nada. Antes de cada unidad de reproducción, ambas implementaciones necesitan un estado lógicamente equivalente, incluidas tablas de referencia, ajustes de funciones, posiciones de secuencia, cortes de lotes y registros creados por pasos anteriores. Esto suele ser más difícil que enviar la solicitud.

Elija el límite de reinicio más pequeño que conserve el significado. Un cálculo puro de presupuesto puede ejecutarse desde un fixture compacto por caso. El cierre de una cuenta puede requerir un escenario ordenado con varias contabilizaciones previas. Un proceso nocturno puede necesitar un punto de control completo de la base y una cola controlada. Reiniciar todo el entorno antes de cada solicitud es lento, mientras que reutilizar una base mutable permite que los casos se contaminen. Agrupe los casos en escenarios independientes, reinicie en sus límites y mantenga el orden de las solicitudes dentro de cada grupo.

No exija esquemas físicos idénticos. Un servicio modernizado con Postgres no debe imitar archivos VSAM ni un archivo físico de AS/400 solo para facilitar la comparación. Construya adaptadores de estado que expresen los mismos hechos empresariales en cada representación. Compare después resultados empresariales observables, no diseños internos de tablas. La paridad arquitectónica anularía el objetivo de la reescritura.

La preparación del estado debe incluir valores que los equipos suelen olvidar: fecha empresarial, base de zonas horarias, configuración regional, metadatos de moneda, modo de redondeo, tablas fiscales, tipos de cambio, semillas de secuencia y contexto de autorización. Fije estas dependencias a una versión del fixture. Si el proceso antiguo lee una tabla de tipos por fecha efectiva y la reescritura usa la fila más reciente de hoy, un JSON de solicitud idéntico sigue planteando problemas distintos.

Verifique la preparación en vez de confiar en el cargador. Antes de ejecutar, calcule una huella semántica compacta, como recuentos y hashes sobre registros empresariales canónicos. Las huellas antigua y nueva no serán idénticas byte a byte entre esquemas, pero pueden afirmar hechos como 418 partidas abiertas, la misma suma de principal por moneda y el mismo conjunto de identificadores de reglas activas. Un fallo de preparación debe detener el caso como inválido, no aparecer más tarde como discrepancia de aplicación.

La comparación exacta empieza con valores canónicos

Compare el dinero como valores decimales con escala y moneda declaradas, nunca como cadenas formateadas ni aproximaciones binarias de coma flotante. La frase «al céntimo» suena sencilla, pero los equipos comparan con frecuencia 12,3 con «12,30», convierten ambos a través de un tipo flotante o redondean solo el total final cuando el programa antiguo redondea cada línea. El arnés necesita el contrato aritmético del dominio.

IEEE 754 explica por qué la coma flotante binaria no puede representar exactamente muchas fracciones decimales. Eso no hace incorrecto todo cálculo flotante. Significa que un épsilon sin explicar es una mala política de paridad financiera. Analice las salidas monetarias como coeficientes y escalas decimales, y aplique la regla empresarial en la misma etapa que el sistema de producción. Si el contrato dice que cada línea de impuesto se redondea alejándose de cero, hágalo antes de sumar. Si indica que una tasa intermedia conserva cuatro decimales, compare ese valor cuando sea observable o añada un diagnóstico específico.

La canonización debe eliminar ruido de representación y conservar el significado. Puede normalizar una marca temporal a UTC, ordenar un conjunto declarado como no ordenado por campos empresariales estables, tratar campos JSON opcionales ausentes según el contrato de API y decodificar un valor de ancho fijo con relleno. No debe convertir a minúsculas identificadores sensibles a mayúsculas, ordenar una secuencia visible para usuarios, eliminar filas duplicadas ni convertir todos los errores en un fallo genérico.

Haga que la política se lea como datos en lugar de enterrarla en el código del comparador:

rules:
  - path: response.total_due
    type: decimal
    scale: 2
    tolerance: 0
  - path: response.generated_at
    type: timestamp
    mode: injected-clock
  - path: outbox[*].headers.trace_id
    mode: ignore
    reason: generated transport identifier
  - path: response.allocations
    mode: ordered

Esa política evita que una limpieza inocente amplíe la tolerancia de toda la batería. Exija un motivo para cada ruta ignorada y cada tolerancia distinta de cero. Revise los cambios de política como código de producción, porque un comparador puede borrar un defecto con más eficacia de la que una reescritura puede crearlo.

Informe de las diferencias en el campo empresarial, no como dos bloques JSON gigantes. Un resultado útil dice invoice.lines[7].tax: legacy 1.34, rewrite 1.35, seguido de la regla de comparación aplicable y la versión del fixture. Incluya recuentos agregados, pero nunca permita que un 99,9 por ciento de coincidencia oculte qué décima falló. Una deducción salarial errónea pesa más que miles de comprobaciones de salud idénticas.

Controle el no determinismo antes de ignorarlo

La mayoría del no determinismo puede convertirse en entrada. Inyecte un reloj, fije la semilla aleatoria, reserve identificadores, congele los datos de referencia y aísle la concurrencia. Cuando ambos programas consumen los mismos valores explícitos, el arnés prueba comportamiento en vez de comparar dos accidentes.

Clasifique cada campo variable en uno de cuatro grupos. Los valores controlados reciben la misma entrada en ambos sistemas. Los valores canónicos difieren en representación, pero se reducen al mismo significado. Los valores ignorados carecen de significado empresarial, como un identificador de traza de transporte. Las salidas estadísticas requieren otra prueba porque una reproducción no demuestra la paridad de un modelo estocástico. Esta clasificación es más precisa que una lista global de exclusión y ofrece a los revisores algo que pueden cuestionar.

El tiempo provoca los fallos evitables más frecuentes. Un proceso puede leer el reloj al recibir la solicitud, al contabilizar y de nuevo al formatear la respuesta. Sobrescribir solo la marca temporal final deja sin controlar la lógica de límites de fecha. Encamine todas las lecturas del reloj empresarial de la reescritura por una fuente inyectable. En el lado antiguo, ejecute en un entorno aislado con hora controlada cuando sea seguro, intercepte su proveedor temporal o capture los valores usados y compare resultados empresariales derivados en un escenario que no pueda cruzar un límite. Nunca cambie el reloj de un host de producción compartido.

Los identificadores generados necesitan correlación, no igualdad, cuando no tienen significado de dominio. Suponga que ambos sistemas crean un nuevo ID de reclamación y después lo usan en tres filas y un evento. Asocie el ID heredado al nuevo en el punto de creación y verifique que todas las referencias posteriores conservan la relación. Ignorar todos los IDs ocultaría una referencia externa rota. Exigir secuencias iguales acoplaría la reescritura a un detalle de implementación.

La concurrencia exige pruebas repetidas y programadas, no una normalización optimista. Si el orden del resultado es irrelevante por contrato, compare un multiconjunto y compruebe también la multiplicidad. Si dos contabilizaciones compiten por el mismo saldo, fuerce ambos intercalados con barreras alrededor de la lectura y escritura disputadas. Una tolerancia amplia no excusa actualizaciones perdidas. Mantenga las pruebas de carga y resistencia separadas de la paridad semántica, pero convierta cualquier fallo hallado allí en un escenario de paridad pequeño y reproducible.

Capture los efectos secundarios, no los duplique

Una reproducción no debe enviar pagos, correos, trabajos de impresión ni mensajes a socios reales. Sustituya el límite por un grabador que acepte la misma orden, devuelva una confirmación controlada y guarde una representación canónica para compararla. El objetivo es demostrar que el sistema nuevo pretendía el mismo efecto, no ejecutar el efecto dos veces.

Coloque grabadores en el último límite bajo su control. Capturar una llamada a función interna puede superar la prueba aunque la serialización, el enrutamiento o las cabeceras sean erróneos. Capturar más allá del límite puede afectar a un tercero. Para un intermediario de mensajes, grabe el tema final, las cabeceras empresariales, el campo de partición cuando tenga significado y la carga después de serializar. En una interfaz de archivos, capture los bytes y una vista empresarial analizada cuando los anchos fijos, las codificaciones o los finales de línea formen parte del contrato.

Los efectos en base de datos necesitan una comparación consciente de las transacciones. Tome una instantánea previa de las entidades empresariales relevantes, ejecute el caso y calcule después el delta. Compare inserciones, actualizaciones, borrados e invariantes entre representaciones. No compare directamente marcas de auditoría ni IDs sustitutos salvo que los consumidores dependan de ellos. Sí compare que los débitos equilibren los créditos, que exista una fila de outbox por acción confirmada y que una reversión no deje cambios empresariales parciales.

Los fallos también son salidas. Haga coincidir clase de fallo, estado, recuperabilidad y efectos secundarios. Puede que no merezca la pena conservar el texto exacto del error antiguo, sobre todo si la reescritura devuelve un error estructurado, pero los llamantes pueden depender de un código o una señal de reintento. Escriba esa regla de compatibilidad. Un reemplazo que convierte un fallo de validación permanente en error de servidor reintentable puede causar más daño que una diferencia visual de un céntimo.

El grabador debe exponer intentos duplicados. Durante los reintentos, compare la idempotencia en toda la secuencia: primera solicitud, confirmación perdida, solicitud repetida y estado final. Ver dos órdenes salientes idénticas no es inofensivo solo porque un entorno de pruebas posterior aceptara ambas.

Una discrepancia necesita un rastro de decisión

Toda discrepancia debe pasar por un flujo breve y explícito: reproducirla, localizarla, clasificarla, asignar responsable y codificar la decisión. Sin ese rastro, los equipos persiguen marcas temporales inocuas durante días o descartan diferencias financieras para proteger una fecha límite.

Empiece reduciendo la reproducción fallida. Conserve su punto de estado, elimine registros no relacionados y reduzca la secuencia hasta que la diferencia permanezca. Examine después el primer valor observable divergente, no el total final. Una diferencia de un céntimo en una factura puede empezar con un redondeo por línea. Otros veinte campos solo la repiten. Guarde el caso reducido junto al arnés para ejecutarlo con cada cambio.

Use un conjunto corto de clasificaciones:

• Defecto de reescritura: la implementación nueva incumple comportamiento heredado aceptado.
• Defecto del arnés: el estado, la captura, la normalización o la observación son erróneos.
• Corrección aprobada: el comportamiento heredado es incorrecto y un responsable autoriza un resultado nuevo.
• Cambio de contrato: la organización cambia el comportamiento deliberadamente más allá de reparar un defecto.
• Sin resolver: aún faltan pruebas o responsable, por lo que el lanzamiento sigue bloqueado para ese caso.

Un registro de aprobación debe indicar caso, campo, valor antiguo, valor nuevo, justificación, aprobador, fecha de decisión y prueba de regresión que ahora define el comportamiento esperado. Evite exenciones libres como «problema de redondeo aceptado». Seis meses después nadie sabrá si cubría una jurisdicción fiscal o todos los cálculos. Haga caducar las excepciones amplias y prohíba comodines sin motivo acotado.

Un artefacto de fallo útil cabe en una revisión sin exponer todo el registro de producción. Incluya entradas saneadas, huella semántica del estado, ambas salidas normalizadas, diferencia estructurada, versión de política y orden de reproducción. Ese paquete permite que un ingeniero reproduzca el resultado mientras el responsable de dominio revisa la consecuencia empresarial real.

Si el sistema antiguo se equivoca, conserve la prueba

Los defectos heredados conocidos deben convertirse en divergencias aprobadas, nunca en trucos del comparador. Primero demuestre que la reescritura difiere. Después demuestre por qué el resultado antiguo incumple la regla elegida. Por último, registre quién asume la decisión de cambiar el comportamiento observable. Así se separa la autoridad técnica de migración de la autoridad empresarial.

El consejo popular de «igualar primero y arreglar después» solo es útil si ese después es real. Reduce variables simultáneas y facilita razonar sobre la migración. Es erróneo si publica un sobrecargo conocido, recrea una autorización insegura o afianza datos corruptos porque nadie programó el segundo cambio. La gravedad y la reversibilidad deciden el orden. Conserve temporalmente rarezas inocuas si eso reduce el riesgo de lanzamiento. Corrija el comportamiento dañino antes del cambio con aprobación y comunicación explícitas.

Pase las correcciones aprobadas por dos afirmaciones. La afirmación de paridad documenta la diferencia intencionada: el sistema heredado produce X y el reemplazo Y. La afirmación de regresión empresarial demuestra Y a partir de una regla o ejemplo independiente. Si elimina más tarde el lado antiguo, la segunda prueba sobrevive como especificación duradera. También impide que un futuro mantenedor «arregle» la reescritura para devolverla al defecto antiguo al ver un caso rojo.

Los datos históricos pueden arrastrar el defecto. Un código correcto puede seguir discrepando con informes antiguos porque los saldos, indicadores de estado o campos derivados guardados ya contienen malos resultados. Decida si va a migrar, recalcular, poner en cuarentena o conservar cada clase de registro afectada. Ensaye esa política de datos en el mismo punto de control usado para reproducir. La paridad de código sin disposición de datos deja incompleto el argumento de cambio.

Comunique el comportamiento cambiado en el límite donde lo noten usuarios o sistemas dependientes. Un importe corregido puede requerir un informe de conciliación. Una validación más estricta puede revelar registros que el sistema antiguo aceptaba en silencio. Una corrección de autorización puede invalidar un flujo. El rastro de decisión debe indicar la respuesta operativa, no solo la justificación aritmética.

El ejecutor heredado necesita una interfaz estable

El arnés debe invocar el sistema antiguo por el límite estable más estrecho que aún ejercite el comportamiento real. Un endpoint HTTP es cómodo cuando ya existe, pero muchos caminos heredados empiezan con un archivo por lotes, un registro de cola, una transacción de terminal o un procedimiento almacenado. Envuelva ese punto de entrada con un ejecutor que acepte el sobre, establezca el contexto, espere a terminar y devuelva las observaciones capturadas en un formato versionado. No reescriba lógica empresarial dentro del adaptador. Cada regla copiada crea otra implementación que puede discrepar.

Trate la salud del ejecutor por separado de la salida de la aplicación. Un tiempo agotado, una región no disponible, una carga de fixture fallida o un error del grabador vuelve el caso inconcluyente. No significa que el sistema heredado devolviera un error y desde luego no cuenta como paridad. Use un sobre de resultado que distinga completed, application_failure e infrastructure_failure, y adjunte logs de trabajo o códigos diagnósticos con retención controlada. Esta distinción impide que una infraestructura de prueba inestable infle la coincidencia aparente.

El aislamiento de recursos importa cuando la plataforma antigua tiene estado global. Dos reproducciones paralelas pueden compartir archivos temporales, nombres de trabajos, generadores de secuencia o una tabla de trabajo que el código productivo supone de un solo escritor. Bloquee esos recursos de forma explícita o asigne espacios de nombres aislados cuando la plataforma lo permita. Si es imposible aislar, serialice el escenario afectado y dígalo en los metadatos. Un arnés rápido que cambia el comportamiento medido aporta peores pruebas que uno más lento y honesto.

Versione ejecutor, adaptadores, política de comparación, fixtures y build candidato en cada resultado. Un identificador de reproducción debe bastar para reconstruir los cinco. Guarde los artefactos por contenido cuando sea posible para que un revisor pruebe que un informe posterior usa las mismas salidas normalizadas. Proteja los paquetes finales según los controles de cambio existentes de la organización. El arnés no necesita otra burocracia, pero sus pruebas deben durar al menos tanto como la aprobación que respaldan.

Por último, pruebe el arnés con diferencias implantadas. Cambie un céntimo, elimine un registro de outbox, intercambie dos asignaciones ordenadas, mueva la fecha empresarial y fuerce una fuga tras reversión en un fixture controlado. Cada mutación debe producir el fallo de campo esperado. Los equipos prueban el código de aplicación constantemente y dan por hecho que el comparador funciona. Un comparador que nunca ha demostrado su sensibilidad es una parte sin probar de la migración.

Las pruebas de lanzamiento deben resistir mejor que una tasa

Un criterio de lanzamiento creíble nombra el comportamiento cubierto y la incertidumbre restante. No dice solo que aprobó el 98 por ciento de los casos. Informe de cobertura por operación y clase de riesgo, cantidad de coincidencias exactas, correcciones aprobadas, fallos del arnés, diferencias sin resolver y límites sin probar. Muestre si la muestra incluye cierre de periodo, reversión, reintento, entrada mal formada, transacciones de alto valor y las formas de datos compatibles más antiguas.

Mantenga el criterio estricto: ninguna diferencia sin resolver en una clase crítica para lanzar, ningún efecto secundario inesperado, ningún cambio de política oculto en el build candidato y ningún fallo de preparación contado como éxito. Las discrepancias de menor riesgo pueden seguir una decisión documentada, pero siguen apareciendo en la prueba. Un denominador que excluye en silencio las reproducciones bloqueadas es fraude de hoja de cálculo.

Ejecute el mismo corpus más de una vez. La repetibilidad detecta tiempo descontrolado, orden, estado compartido y fugas del entorno. Después reproduzca una captura reciente reservada que los desarrolladores no usaron para ajustar la reescritura. Un corpus puede convertirse en un objetivo sobreajustado igual que una batería unitaria. La reserva no necesita ser enorme. Necesita procedencia representativa y protegida, además de un método de muestreo documentado.

En el cambio, la ejecución en sombra puede aportar pruebas si el sistema lo permite de forma segura. Envíe una copia de lecturas u órdenes activas aptas al reemplazo, suprima sus efectos y compare resultados fuera del camino del usuario. Nunca deje confirmar la operación a ambos lados. Vigile privacidad, capacidad y cambios temporales introducidos por la propia ruta en sombra.

CodeHero utiliza tráfico de producción grabado y un arnés de paridad para sujetar los sistemas reescritos en Go, Rust y TypeScript al comportamiento original mientras cambia su arquitectura. En un proyecto entregado en menos de 30 días, esa prueba debe diseñarse al inicio, no reunirse en la reunión de lanzamiento.

El paquete de aceptación también debe mostrar lo que la reproducción no demostró. Enumere las operaciones sin captura utilizable, integraciones representadas solo por un stub, antigüedades de datos ausentes de los fixtures y patrones de concurrencia probados únicamente bajo carga. Para cada hueco, indique la prueba compensatoria, como una batería de regresión específica, una consulta de conciliación, un ensayo preparado con operadores o una observación limitada después del cambio. No convierta esos controles en afirmaciones de paridad. Responden a otra pregunta y deben conservar esa etiqueta. Así quien aprueba el lanzamiento puede juzgar un riesgo acotado en vez de suponer que una gran cantidad de casos cubre todos los caminos. Adjunte este registro de huecos al resultado final, porque será el primer plan de pruebas para la supervisión productiva y el siguiente ciclo de captura. Si aparece una operación no representada durante la sombra, añádala al corpus con su procedencia intacta. La prueba mejora cuando los casos nuevos amplían un límite declarado. Pierde credibilidad cuando el equipo cambia en silencio el significado de cobertura.

Un arnés de paridad gana confianza por las diferencias que se niega a ocultar. Haga reproducibles las entradas, equivalente el estado, explícita la aritmética, clasificados los campos variables y responsables las excepciones. Así el último caso rojo es una prueba útil, no un obstáculo que haya que pintar de verde.