Pruebas de mutación en Android. ¿Vale la pena? | autor: Phellipe Silva | Octubre de 2020

Traducción en portugués aquí 🇧🇷

Como consultor de Android en ThoughtWorks, tuve el privilegio de seguir de cerca la transformación digital de Natura & CO. Una transformación constante y necesaria para que Natura se diferencie en el mercado y amplíe el desarrollo de sus productos digitales. Lo interesante de este tipo de transformación organizacional es que quien lo usa tiende a obtener mejores pautas para un buen desarrollo de software, mejores procesos de entrega y, en consecuencia, una mayor calidad del producto lanzado.

Reflexiones de este diGRAMOLa transformación italiana ha llegado al equipo en el que estoy trabajando, la tribu financiera de Natura. Aquí tuvimos la oportunidad de realizar una investigación del tipo de prueba automatizada, que en mi opinión es muy interesante y a la vez desconocida para mucha gente en el mundo de Android. Estos son pruebas de mutación. Nuestro objetivo era comprender si este tipo de prueba podría agregarse a nuestro proceso de entrega y mejorar la calidad de nuestra aplicación de Android.

En el caso concreto de este artículo, hablaremos pruebas de mutación en Android con Kotlin.

El objetivo de este tipo de pruebas es básicamente dar respuesta a una pregunta única, directa y compleja:

¿Están realmente bien implementadas las pruebas automatizadas de su proyecto?

El objetivo de las pruebas de mutación es garantizar la calidad de su kit de prueba. El objetivo es comprobar si sus pruebas automatizadas son realmente capaces de detectar fallas o no.

Su código de producción será probado directamente por herramientas tradicionales de Android como JUnit, Espresso, Robolectric, etc.… e indirectamente probado por herramientas de prueba de mutación.

En este artículo, compartiremos las herramientas que analizamos y los resultados de esta encuesta.

Para asegurarse de que sus pruebas automatizadas estén bien implementadas, primero se realizará una prueba de mutación aplicar un cambio aleatorio a un punto específico en su código de producción. Este cambio generado automáticamente se llama mutación.

Ejemplos de mutaciones aplicadas al código de producción para verificar si el número es negativo o no

Después de aplicar el cambio, la herramienta de prueba de mutación ejecuta su conjunto de prueba automatizado sobre el código original y también sobre el código modificado.

Diagrama que muestra cómo funcionan las pruebas de mutación

Debido a que todas las pruebas realizadas en el código original han pasado cuando la herramienta realiza las mismas pruebas en el código mutado, pueden ocurrir los siguientes escenarios:

  • 1 # Se aprobaron las pruebas realizadas en el código original, pero fallaron las mismas pruebas realizadas en el código mutado. Esta indica que las pruebas de cambios adversos han fallado, lo que lleva a la conclusión de que se ha detectado la mutación utilizada y la prueba está bien implementada 👍 ✅
  • 2 # Las pruebas realizadas en el código original han pasado y las pruebas realizadas en el mutante también han pasado. Esto indica que su prueba está mal implementada, porque incluso con un cambio aleatorio en su código de producción, su prueba aún pasa y no identificó nada 👎 🔴
  • 3 # Ninguna prueba cubrió la región mutada, lo que significa que su kit de prueba no cubre partes de su código que pueden ser propensas a errores 🔴 🔴

Tenga en cuenta que cuando ejecutamos una prueba de código mutado, la falla es una señal positiva. Esto significa que se pueden identificar posibles errores en esta área y las pruebas garantizan la calidad y el comportamiento del código.

Un punto interesante que vale la pena mencionar es no es necesario escribir código adicional utilice este análisis. Solo necesitamos configurar la herramienta correctamente y utilizará todo lo que ya existe en el proyecto para usted. Como resultado, la herramienta de prueba de mutaciones también puede generar informes que describen cuántas mutaciones se han detectado y cuántas aún no se han detectado:

Prueba de mutación mensaje de ejemplo. De las 5 mutaciones utilizadas en el código de producción, solo se detectaron 3.

En conclusión, me gustaría compartir una frase que me gusta mucho y genera una idea interesante sobre el proceso de escritura de la prueba:

«Nunca confíes en una prueba que no hayas visto fallar personalmente»
– Autor desconocido

Si desea utilizar pruebas de mutación en el entorno Java y JVM (Java Virtual Machine), tenemos varias opciones. Muchos de ellos no se conocen en el campo de la ingeniería de software y no tienen ejemplos de uso real en grandes sistemas.

De las herramientas examinadas en este estudio de caso, solo una surgió como candidata potencial para un proyecto de Android a gran escala. Esa herramienta fue Pitest. Además de ser la herramienta con la mejor documentación y una configuración más sencilla, también fue mejor valorada en las escalas probadas. Por esta razón, Elegimos Pitest como principal herramienta a analizar en esta prueba de concepto..

Para ilustrar a continuación, encontrará un ejemplo que compara diferentes herramientas para probar mutaciones para Java, incluido Pit (est):

Resultado valores de referencia realizados Adnan Shaout

Pitest es una herramienta de prueba de mutaciones de última generación Java y JVM (como se indica en su página principal). El gran desafío que tenemos en Android es: Las aplicaciones modernas ya no usan Java y Android en la JVM no funciona.

Como sabemos, Kotlin es el idioma oficial recomendado por Google para nuevos proyectos de Android. Adicionalmente, Android tiene su propia máquina virtual, que es una versión más ligera de la JVM con códigos de bytes DEX en ejecución.

Al intentar usar Pitest en Android, pronto nos dimos cuenta de ciertas limitaciones (que otras personas han experimentado):

Pitest GitHub problema sobre cómo iniciar Android
Pitest GitHub problema sobre la ejecución de Kotlin

Porque Pitest es fuente abierta y un proyecto en constante actualización, los creadores y la comunidad intentaron solucionar estos problemas creando plugins específicos para cada situación. Un complemento para la integración Mejor con Android y el otro a la integración Lo peor con Kotlin. Desafortunadamente, no se ha desarrollado una solución específica para satisfacer las necesidades de los proyectos de Android con Kotlin 😢

A pesar de las restricciones presentadas, la investigación continuó monitoreando lo que sucedió cuando aplicamos el complemento Pitest para Android a un proyecto de Android que está escrito íntegramente en Kotlin.

El alcance de esta encuesta consistió en el análisis de un proyecto escrito íntegramente en Kotlin utilizando todas las funciones que ofrece el lenguaje. Siempre intentamos escribir código idiomático con un fuerte uso de Coroutines.

¿Cómo se comportó Pitest (en su estado actual) hasta este punto?

Spoiler: Desafortunadamente, la respuesta de Pitest (usando el complemento de Android) no fue satisfactoria para el contexto del proyecto de Android con Kotlin. Por esta razón, no recomiendo la práctica de probar mutaciones en un gran proyecto de Android usando las herramientas que tenemos disponibles hoy (Out / 2020).

Lo más lamentable al usar mutaciones con respecto a algunas palabras clave, Kotlin no funcionó muy bien. El era uno de ellos cuando La palabra clave que generó el siguiente error en algunos escenarios:

The class com.example.demo.TestClass$WhenMappings does not contain a source debug information.All classes must be compiled with source and line number debug information

También tuvimos problemas con algunas otras clases que usaban anotaciones como @Parcelize genera un error similar en el código.

The class com.example.demo.Model$Creator does not contain a source debug information.All classes must be compiled with source and line number debug information

En el caso de Coroutines, está claro que se trata de un complemento específico de Kotlin aún no es compatible Esta característica.

Existen artículos compartiendo problemas similares al intentar aplicar pruebas de mutación a proyectos de Android con Kotlin. Una alternativa para resolver estos problemas sería ignorar algunas clases específicas y considerar solo clases más simples al usar mutaciones. En algunos casos, la herramienta funcionó correctamente al realizar este tipo de ajustes.

Dado el resultado que obtuvimos, nos enfrentamos al siguiente dilema: ¿Deberíamos adoptar una nueva herramienta en nuestro canal de entrega para usar pruebas de mutación solo para clases simples que no usan muchos recursos de Kotlin? ¿O sería mejor no utilizar pruebas de mutación debido al esfuerzo que tendríamos para mantener la herramienta?

Dadas las dificultades encontradas, hemos llegado a la conclusión de que el esfuerzo por mantener una nueva herramienta será superior al valor que aporta. Por lo tanto, actualmente no recomendamos incluir una herramienta de prueba de mutaciones en un gran proyecto de Android con Kotlin.

Asegurar una buena implementación de la prueba es una tarea difícil que requiere disciplina. Sin embargo, algunos pasos pueden ayudar a que este viaje sea menos doloroso. Para hacer esto, puede:

  • Promover las mejores prácticas al utilizar pruebas unitarias en el servicio. Java y Kotlin.
  • Hazlo bien probando la estrategia piramidal que su equipo puede seguir fielmente.
  • Priorice el comportamiento de las pruebas sobre las pruebas de implementación. Una buena fuente sobre este tema es libro Principios, procedimientos y patrones de prueba unitaria escrito por Vladimir Khorikov.
  • Conviértete en una persona junto a las métricas de calidad de tu equipo.
  • Fortalecer la práctica de TDD. Si no puede aplicar TDD a su equipo, deje que la prueba falle al menos una vez antes de hacerlo.

Aunque no recomienda el uso de herramientas de prueba de mutaciones en grandes proyectos para Android con Kotlin hoy, reconocemos el gran trabajo con el que trabajan Pitest lo hacen por nuestra comunidad. Quizás con un poco más de energía y más personas contribuyendo a estos increíbles proyectos, podríamos tener una herramienta más sólida para usar en nuestros proyectos de Android en un futuro cercano.

Esperamos que este artículo haya contribuido a algo en su viaje técnico. ¡Háganos saber cualquier pregunta o comentario en la sección de comentarios a continuación! ¡Gracias!

¡Gracias también a Poliana Florencio, Lucas Valadã, Lucas de Souza da Conceição y Eduardodribas por leer este artículo!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *