El artículo está basado en una publicación en el canal de telegramas Cross Join .
Antes de hablar sobre este enfoque, primero explicaré en pocas palabras qué es la prueba de mutación en general. Para aquellos que no están al tanto.
Prueba de mutación
Cuando escribe pruebas, TDD o no, incluso con una cobertura formal del 100%, nunca estará seguro de que todo esté realmente probado en el código. Por ejemplo, es posible cometer un error cursi al llamar a assert en la propia prueba.
assertEquals($a, $a);
Y si incluso durante la prueba fue posible alcanzar algún si, no es un hecho que todas las condiciones en este si se hayan verificado correctamente.
Para asegurarse de que las pruebas sean realmente probables, existe una manera: introducir errores en el código usted mismo y ver si las pruebas se salen de esto. Si las pruebas siguen siendo verdes con un error obvio, entonces no todo ha sido probado.
Por ejemplo, cambió el más por un menos, o agregó "no" a la condición, y ver si las pruebas reaccionaron. Este enfoque se llama "Prueba de mutación".
Esto generalmente se hace en áreas muy críticas de programación, donde los errores generalmente no están permitidos. Por ejemplo, software móvil o software médico.
Por supuesto, en la construcción de un rover, todo esto se hace automáticamente: una herramienta especial desfigura su programa y mira si las pruebas han fallado.
, , , , , . : AST, .
Mutation Driven Development
mutation driven development. TDD, .
- , ( )
- ( if). , , MDD (?) , 100% overage TDD.
, CI, , , MDD .
, , . mutation driven testing , . , .. , , , , , ., 95% , - -. , .
Por supuesto, discutiremos el desarrollo impulsado por mutaciones en una de las próximas ventas de zinc , no olvide suscribirse al podcast