Ver todas las pruebas en verde tranquiliza. Si todas pasan, el código debe de estar bien. Pero un conjunto de pruebas que pasa solo te dice que no está roto nada de lo que las pruebas comprueban. No dice nada de lo que nunca comprueban. Por eso probamos las pruebas, rompiendo nuestro propio código a propósito.
Una prueba que no puede fallar no es una prueba
Imagina una regla: hay que tener dieciséis años para tener una cuenta. Alguien escribe el código y una prueba. La prueba comprueba que se acepta a alguien de treinta años y se rechaza a alguien de diez. Pasa.
Ahora cambia un solo carácter de la regla:
// la regla
const mayHoldAnAccount = (age: number) => age >= 16;
// la misma regla, rota a propósito
const mayHoldAnAccount = (age: number) => age > 16;Ahora se rechaza a alguien de dieciséis años. ¿Lo nota la prueba? No. Treinta sigue entrando, diez sigue fuera y todo sigue en verde. La regla está mal y nada nos avisó.
Pruebas de mutación, con palabras sencillas
Ese pequeño fallo deliberado se llama mutante. Hacer pruebas de mutación consiste en crear muchos, de uno en uno, y ejecutar las pruebas contra cada uno:
- Cambia una cosa pequeña del código: invierte una comparación, quita una comprobación, cambia un valor.
- Ejecuta las pruebas.
- Si una prueba falla, el mutante queda atrapado. Bien.
- Si todas siguen pasando, el mutante ha sobrevivido y falta una prueba. La escribimos.
En el ejemplo, basta con una prueba más: se acepta a alguien de dieciséis años. Con esa prueba, la regla rota pone todo en rojo al instante.
Cómo lo usamos
Ese orden importa. Una prueba que nunca hemos visto fallar quizá no esté probando nada. Verla en rojo primero demuestra que atraparía el fallo para el que se escribió.
Los mutantes no son la única comprobación. Cada cambio pasa también por todas las pruebas. A parte del código le damos grandes cantidades de datos aleatorios, para encontrar los casos que a nadie se le ocurrió escribir. Un servidor de verificación vuelve a ejecutar las pruebas, parte de los mutantes y búsquedas de secretos filtrados según un calendario, e informa de lo que encuentra. Al final de cada fase, unos revisores se esfuerzan por romper lo que hemos construido antes de darlo por terminado.
Lo que no demuestra
Las pruebas de mutación te dicen que tus pruebas notarían los fallos que has metido. No pueden demostrar que el código no tenga ningún fallo, y no sustituyen a una auditoría independiente. Por eso, en el seguimiento, nada que espere una auditoría puede aparecer como terminado, pase las pruebas que pase.
Por qué te importa
Cuando una parte del trabajo avanza en nuestro seguimiento, es porque ha cambiado un repositorio, y ese cambio ha pasado antes por estas comprobaciones. Nadie puede escribir una cifra a mano. Preferimos enseñarte una barra más lenta y cierta que una más rápida y falsa.