¿Quién está probando las pruebas?

sobre cómo la prueba de mutación puede ayudar a mejorar la calidad de tus pruebas. Pero antes de sumergirnos en la prueba de mutación, primero quiero hablar un poco sobre la cobertura de código. La cobertura de código se utiliza a menudo por los desarrolladores como una forma de medir la calidad de sus pruebas. En mi opinión, es una métrica deficiente para medir esto. Lo único que la cobertura de código realmente prueba es si el código se ejecuta o no. La razón por la que escribo pruebas unitarias es verificar que mi código funcione correctamente en este momento y asegurarme de que siga funcionando en el futuro. Y si algo sucede y mi código se comporta de manera diferente, obtendré una prueba fallida. Y nuevamente, la cobertura de código no mide esto, solo mide si se ejecuta tu código. Entonces, ¿cómo medimos realmente la calidad de tus pruebas? Bueno, eso nos lleva al tema de esta charla, la prueba de mutación. La prueba de mutación es una forma de insertar errores en tu código fuente para probar si tus pruebas pueden detectarlos. ¿Cómo funciona esto? Bueno, un marco de prueba de mutación comenzará con tu código fuente, que está todo bien y no hay nada malo con él. Luego hará una pequeña mutación en tu código fuente, lo que generará un mutante. Por ejemplo, A más B podría mutar a A menos B. Esto dará como resultado un resultado diferente para tu código fuente. Y debido a que tu código fuente ha cambiado, debería provocar una prueba fallida. Entonces, el marco de prueba de mutación ejecutará tus pruebas y puede tener dos resultados. O bien, el mutante ha sido detectado debido a una prueba fallida, en ese caso el mutante ha sido eliminado, o ninguna de tus pruebas falló y el mutante pudo sobrevivir. En la prueba de mutación, queremos haber eliminado los mutantes. Entonces, queremos que las pruebas realmente fallen porque hemos insertado un error. En el marco de prueba de mutación, haremos esto cientos o miles de veces para tu código fuente, y al final, lo combinaremos todo y generaremos un informe completo.

Entonces, ¿cómo funciona esta mutación en el código real? Bueno, aquí tengo una pequeña función JavaScript en la parte superior para verificar si un cliente tiene permitido comprar alcohol. Este cliente tiene permitido comprar alcohol en este país si la edad es al menos 18. Y a continuación tengo una prueba para el Profesor X, que tiene 96 años y, por lo tanto, tiene permitido comprar alcohol. En la prueba de mutación miramos el código fuente anterior y hacemos un pequeño cambio. En este caso, el signo mayor o igual se cambiará por un signo menor que, invirtiendo así la comprobación. Si hacemos este cambio en nuestro código fuente, la prueba fallará, por lo tanto, el mutante ha sido eliminado. Esto demuestra que tenemos una prueba para este caso específico y este error no puede insertarse en nuestro código sin que lo sepamos. También podemos cambiarlo de otra manera.

Por ejemplo, podemos cambiarlo a mayor que. Comenzamos con mayor o igual, ahora es mayor que. Dado que solo tenemos un caso de prueba para alguien de 96 años, todas nuestras pruebas pasan y el mutante ha sobrevivido. También podemos cambiar toda la declaración de retorno y simplemente devolver siempre 2. En nuestro caso, aún pasa y tenemos un mutante sobreviviente.

Este es un código muy simple. La mayoría de nuestro código no se parece a esto y la mayoría de nuestras pruebas también son más complicadas. Si alguien mira este código, podría decir, `oye, obviamente te faltan algunos casos de prueba`, en el código de producción que estamos escribiendo, a menudo es mucho más difícil. Entonces, ¿qué tipo de mutaciones puedes esperar para los marcos de prueba de mutación? Bueno, la lista definitiva depende del marco y del lenguaje que estés usando. Pero en la mayoría de los casos, son posibles mutaciones como esta. Por ejemplo, cambiar el signo más por un signo menos, vaciar cadenas, vaciar matrices, invertir operaciones, puedes hacer muchas cosas con un cambio muy pequeño en tu código. Y solo uno de estos cambios estará activo a la vez para asegurarnos de qué mutación está causando que una prueba falle. Bueno, la prueba de mutación está disponible para muchos marcos diferentes. Y como estamos en una conferencia de JavaScript, recomendaría striker.js como el marco a usar para JavaScript y TypeScript. Pero está disponible para casi todos los lenguajes que conoces. Si no está en esta lista, simplemente búscalo en Google para tu lenguaje y probablemente encontrarás algo. Entonces, para striker.js, tengo una pequeña demostración. La aplicación de demostración que tenemos también está disponible en nuestro sitio web. El enlace estará al final de las diapositivas con información sobre cómo configurarlo tú mismo. Puedo iniciar striker desde la línea de comandos. Y comenzará a ejecutar nuestras pruebas. Como la aplicación de demostración es pequeña, es bastante rápida. Si tienes una aplicación enterprise grande, es probable que notes que la prueba de mutación es bastante más lenta que la ejecución de la prueba unitaria. Debido a que se realizan miles de mutaciones y cada una de ellas debe ser probada. Entonces, mi computadora portátil se está iniciando ahora mismo. Está testing. Y en uno o dos segundos, estará terminado. Para nuestra aplicación, tiene 12 archivos fuente para mutar y pudo generar 126 mutantes. Así que está hecho.

Aquí obtenemos una tabla agradable como resultado. Pero también tenemos un informe HTML. Y si miramos este informe, podemos ver que tenemos una puntuación de mutación. Esa es la cantidad de mutantes que pudimos eliminar. Cuantos más mutantes elimines, mayor será tu puntuación. Y al igual que con la cobertura de código, probablemente quieras una puntuación alta. En este caso, hemos obtenido aproximadamente el 85% de nuestra aplicación. Bueno, si miramos la cobertura de código para esta aplicación, tendríamos una cobertura de código del 100%. Entonces, si solo usamos la cobertura de código como métrica, estaríamos engañados pensando que hemos probado esto correctamente. Ahora, si miramos archivos específicos, también puedes ver mutaciones específicas, por ejemplo, el H-check aquí, y notamos que tenemos un operador de igualdad que sobrevive. Para mí, esto indica que nos falta una prueba porque pudimos cambiar el signo mayor que por mayor o igual. Entonces, en un informe como este para tu código fuente, realmente puedes descubrir qué tipo de pruebas te faltan o si tienes algún error en tus pruebas. En resumen, la prueba de mutación en mi opinión es una herramienta mucho mejor para medir la calidad de tus pruebas. Te recomendaría encarecidamente que lo pruebes. Para JavaScript y TypeScript, recomiendo Stryker. Hay un ejemplo disponible en nuestros sitios web. Si tienes alguna pregunta, no dudes en contactarnos en Twitter en Stryker en el mutador cuadrado, y las diapositivas también están en GitHub.