Extreme mutation testing

0
247

Extreme mutation testing es una técnica relativamente nueva que nos ayuda a revisar si tenemos buenos casos de prueba de forma computacionalmente más eficiente que el mutation testing clásico.

Como sabemos, tener una buena batería de tests automáticos es fundamental en cualquier desarrollo, ya que ayudan a detectar de forma rápida y eficiente cualquier fallo que se haya introducido en nuestro código.

Normalmente se mira la cobertura por línea, que nos dice si una línea se ha ejercitado, pero no nos dice si estamos usando buenos casos de prueba, sólo si la línea se ejecuta. Podemos usar mutation testing para ver si estamos usando buenos casos de prueba.

Sobre mutation testing se ha hablado en mutation testing con pit y se recomienda su lectura. En este artículo nos centraremos en pit-descartes que es el motor que usa pit para hacer extreme mutation.

Este tipo de mutation testing fue propuesto en el paper Will My Tests Tell Me If I Break This Code?. Las ventajas que ofrece es que muta no a nivel de operadores, sino a nivel de método, lo que nos hace tener muchos menos mutantes dándonos una mayor rapidez y un buen punto de partida para saber donde tenemos que poner el foco en mejorar.

Índice de contenidos

  1. Introducción
  2. Entorno
  3. Extreme mutation testing
  4. Mutaciones
  5. PIT
    1. El proyecto de ejemplo
    2. Uso de PIT a través de Maven
  6. Conclusiones
  7. Referencias

1. Introducción

Mutation testing es una herramienta muy útil para ver cómo de buena es nuestra base de tests. Si bien, la mutación guiada por operadores puede ser lenta, es más precisa que la mutación extrema. La mutación extrema nos puede dar una primera visión del estado de nuestros tests, y luego pasar a una mutación clásica.

Es muy importante tener una buena cobertura de test con buenos casos de prueba (no solo aquellos que hacen que el código se ejecute) para que cuando se hagan modificaciones en el código, se detecten el mayor número de errores posibles. Con estas herramientas nos aseguramos que el ejercicio del código está realizado en base a unos valores y aserciones correctas.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Lenovo t480 (1.80 GHz intel i7-8550U, 32GB DDR4)
  • Sistema Operativo: Pop OS 20.04 5.11.0-7620-generic #21~1626191760~20.04~55de9c3-Ubuntu.
  • Entorno de desarrollo: IntelliJ IDEA 2021.2 (Ultimate Edition).
  • Apache Maven 3.8.1.
  • JDK AdoptOpenJDK-11.0.11+9

3. Extreme mutation testing

En los últimos años, ha surgido una variante del mutation testing que se hace llamar extreme mutation testing.

Esta variante surge de la necesidad de aumentar el rendimiento del mutation testing, siendo computacionalmente menos exigente.

Se basa en la idea de que en vez de mutar operadores o instrucciones, lo que hace es mutar métodos.

Si un método es mutado y a pesar de tener cobertura el test sigue pasando, es que no se está probando de forma adecuada, lo que se conoce como que los métodos están «pseudo testeados».

Como siempre vamos a tener menos métodos que operadores o instrucciones, se van a generar menos mutantes lo que hace que sea computacionalmente más rápido que el mutation testing tradicional.

4. Mutaciones

Cuando se mutan los métodos, los mutantes particulares tienen que sobrevivir para que un método se considere pseudo testeado.

A los métodos que no devuelven nada (void), se les vacía el cuerpo y si ese mutante resultante sobrevive, el método se clasifica como pseudo testeado. Si a un método se le quita el cuerpo y el test sigue pasando, es que hay algo raro ¿verdad?.

Para métodos que devuelven valores, lo más normal es que varias mutaciones tengan que sobrevivir.

Por ejemplo, si un método devuelve un booleano, dos mutantes tienen que sobrevivir. Para este caso se reemplaza el cuerpo del método con dos mutaciones, una que devuelve true y otra que devuelve false.

De las mutaciones anteriores miramos la supervivencia de los mutantes: si ambos mutantes sobreviven, el método se clasifica como pseudo testeado, pero si solo uno sobrevive, el método se clasifica como parcialmente probado.

Boolean sería el caso más fácil por solo tener dos valores, otros tipos como enteros (0, 1, 2, 3 … Etc.), cadenas («», «Cadena», «otra cadena») se eligen valores para que si los mutantes sobreviven, el método pueda ser categorizado como pseudo testeado.

Los objetos pueden ponerse a null.

La elección de los valores que se utilizan para la mutación depende de la herramienta de mutación. pitest-descartes es configurable y tiene estos valores por defecto.

5. PIT

En este artículo solo se va a hacer uso del plugin de maven y el código será el mismo que en el otro artículo pero con Junit5.

5.1. El proyecto de ejemplo

Tenemos una clase calculadora:

Y sus correspondientes tests:

Los tests están con Junit5 y hamcrest, por lo que necesitamos sus dependencias:

Antes de hacer nada, comprobamos que los tests pasan.

Todos los tests pasan
Todos los tests pasan

5.2. Uso de PIT a través de Maven

Para usar pit con maven, necesitamos añadir el plugin al pom.xml, tal y como se ve a continuación:

Es importante ver que dentro de dependencias tenemos dos: una es el plugin para poder usarlo con junit 5 (pitest-junit5-plugin) y la otra es el motor para hacer extreme mutation testing (descartes). También observamos que la configuración indica que estamos usando el motor descartes:

Otra cosa que necesita PIT es un engine para junit, por lo que necesitamos añadir la siguiente dependencia:

Si no añadimos esa dependencia, tendremos un error similar a este:

Si ejecutamos:

Podemos ir a target/pit-reports/[FECHA] y vemos el index.html con la información.

Desde la consola también se nos da información:

Informe de cobertura
Informe de cobertura

Lo que podemos observar es que aunque tenemos cobertura en todas las líneas, nos está fallando una mutación y nuestros tests podrían ser mejores.

Si entramos en el detalle:

Detalle del informe
Detalle del informe

Lo que nos está diciendo es que en el caso de la multiplicación, si cambia lo que devuelve el método por 1 y ese mutante sobrevive, lo que nos indica que ese test no está probando bien.

En efecto es así, porque hemos elegido multiplicar 1 * 1, el cual es un caso de prueba malo porque no nos permite detectar errores (1 / 1 = 1, o simplemente return firstNumber darían como bueno ese test).

Si cambiamos el test para que sea:

Ahora tenemos un mejor caso de prueba.

Si volvemos a ejecutar:

mvn test && mvn org.pitest:pitest-maven:mutationCoverage

Vemos que tenemos una cobertura del 100% en líneas y también en mutación.

Detalle del informe tras la mejora
Detalle del informe tras la mejora

6. Conclusiones

Con el extreme mutation testing podemos con un menor coste computacional hacernos una idea de cómo de buenos son nuestros tests.

Este menor coste computacional es debido a que se hacen menos mutaciones, pero puede ser un buen punto de partida para ver en que estado está un proyecto e ir mejorando, y luego tener un grano más fino con los tests de mutación clásicos.

7. Referencias

Dejar respuesta

Please enter your comment!
Please enter your name here