Ejecutar pruebas de mutación sin ahogarse en supervivientes

Objetivo

Usar las pruebas de mutación como una comprobación rutinaria de que las pruebas detectan fallos, sin convertirlas en un cuello de botella de CI ni en un informe lleno de supervivientes que nadie atiende. Si la puntuación predice defectos que se escapan es una hipótesis aparte; esta es el procedimiento operativo.

Requisitos previos

Una suite de pruebas unitarias determinista e independiente del orden; una herramienta de mutación para el lenguaje (PIT para la JVM, StrykerJS para JavaScript y TypeScript, mutmut para Python, cargo-mutants para Rust); cobertura de líneas ya medida, dado que el código sin cobertura solo produce mutantes «sin cobertura».

Pasos

1. Ejecutar la herramienta sobre un módulo con lógica, no sobre toda la base de código, y leer el informe. La documentación de PIT enumera los resultados por mutante: killed (eliminado), survived (superviviente), no coverage (sin cobertura), timed out (tiempo agotado), además de los estados non-viable y error. La página de métricas de Stryker define la puntuación de mutación como los detectados divididos entre los mutantes válidos, donde detectados cuenta tanto los eliminados como los que agotaron el tiempo.
2. Abrir cada superviviente en el código. Es una de tres cosas: una aserción faltante (la prueba ejecutó la línea pero no comprobó nada que dependa de ella), un caso faltante (un límite al que ninguna prueba llega), o un mutante equivalente que no puede cambiar el comportamiento observable, que la documentación de PIT ilustra con >= 1 frente a > 1 cuando el valor siempre es 2.
3. Corregir los dos primeros tipos reforzando las pruebas. Para los equivalentes, excluir el mutador o anotar la línea según lo permita la herramienta, en lugar de escribir pruebas artificiosas.
4. Acotar el tiempo de ejecución: limitar la ejecución a los archivos cambiados o usar el modo incremental (--incremental de StrykerJS reutiliza los resultados de los mutantes cuyas pruebas de cobertura no cambiaron); fijar un tiempo límite por mutante; desactivar los mutadores que solo generan ruido para la base de código (PIT omite por defecto las líneas con llamadas a frameworks de logging habituales).
5. Poner la ejecución acotada en la CI sobre el diff y una ejecución completa programada con el informe publicado, sin que bloquee.
6. Seguir la puntuación por módulo y usarla como un trinquete («no menor que la última ejecución») en lugar de un objetivo global fijo.

Resultado esperado

Cada cambio produce, antes de la revisión, una lista corta de aserciones faltantes concretas, y la puntuación de los módulos que importan sube lentamente en lugar de discutirse sin fin.

Límites y base de verificación

El tiempo de ejecución se multiplica con el número de mutantes, y las pruebas inestables o dependientes del orden vuelven los resultados carentes de sentido. Las puntuaciones no son comparables entre herramientas ni entre conjuntos de mutadores. Una puntuación alta en código trivial dice poco; el esfuerzo debe dedicarse a los módulos con lógica de ramificación. No se afirma ninguna medición.