Estrategias de prueba en Android: Parte 2: Pirámide y cobertura | Autor: Natan Ximenes | Septiembre de 2021
Si ha oído hablar de la pirámide de pruebas, es probable que ya la haya asociado o confundido con la estrategia de prueba.
Por lo general, primero estudie la prueba, luego comprenda la pirámide y úsela como una regla en lugar de una herramienta de guía.
En el primer artículo de esta serie, he explicado qué es realmente una estrategia de prueba. Puede leerlo aquí:
Teniendo en cuenta la ejecución y la mantenibilidad, la pirámide de pruebas es una forma ideal de distribuir los tipos de pruebas que deben incluirse en una aplicación, siguiendo el siguiente esquema:
Prueba unitaria del 70% – Prueba de integración del 20% – Prueba de interfaz de usuario al 10%, El resultado es 100%.
Entonces, en un Para los proyectos de Android, podemos aplicar la pirámide de pruebas, donde tendrá una gran cantidad de pruebas unitarias (validando clases o funciones), una cantidad ponderada de pruebas de integración (validando el flujo de datos a través de la unidad) y una pequeña cantidad de pruebas de UI. (porque puede requerir más tiempo para ejecutarse).
Sin embargo, no es necesario que el conjunto de pruebas de la aplicación sea adecuado para esta geometría. Imagina bibliotecas como Room, Retrofit, Koin, Coroutines, RxJava … Todas son bibliotecas de Android, pero ninguna de ellas proporciona funciones de renderizado de UI.
Esto significa que la pirámide en realidad no tendrá forma de pirámide, porque la prueba de IU que representa la parte superior no se puede aplicar.
Puede (no necesariamente) parecerse al diagrama de la izquierda, donde solo se aplican pruebas unitarias y de integración.
Por lo tanto, la pirámide representa una distribución de suite de pruebas ideal, que se basa en la interconexión entre el tiempo de ejecución y la capacidad de mantenimiento del proyecto front-end.
No se puede considerar como una regla absoluta, porque no se aplica a todos los tipos de aplicaciones y el método de distribución es diferente según la estrategia de prueba. Este es un artículo con un enfoque diferente Mostrar trofeo de prueba.
A continuación se muestra un ejemplo:
Hay una aplicación completa o una parte de ella es un simple «espejo» de la API de back-end que devuelve los datos necesarios para que se muestren en la pantalla. No se trata de lógica empresarial o procesamiento de datos.
En este caso, la mejor manera es realizar pruebas unitarias repetidas en la clase que actúa como un proxy simple (una clase que llama a otro valor de retorno), o afirmar la integración de retorno de un grupo de clases que trabajan juntas en la prueba de la capa de aplicación. ?
La respuesta es simple: depende de la situación.
Depende de lo que sea más importante para el equipo en este momento (tiempo, mantenibilidad, costo de ejecución, fidelidad, etc …), y también depende de cómo se expandirá el proyecto en el tiempo.
A lo largo del ciclo de vida del producto, las cosas pueden cambiar. Mercados, necesidades, usuarios, herramientas, frameworks, etc. La estrategia de prueba debe evolucionar a la misma velocidad para adaptarse al mejor método actual.
Lo único que puede ser 100% seguro es que la pirámide de prueba no puede decirle cuál es el mejor enfoque, porque no es una estrategia de prueba. Es solo una herramienta de guía.
Nos dice qué probar, pero no cómo probarlo correctamente, no considera la particularidad de la aplicación, no encuentra la importancia de enfocarse en puntos de falla comunes y no puede servir como equipo de documentación. Por tanto, no es una estrategia de prueba.
Noah Sussman reinventó la pirámide de prueba de una manera diferente, como si fuera un filtro de error. Es la misma forma geométrica, pero invertida.
Sirve para más propósitos para la pirámide de prueba, porque parece más que una simple sugerencia de distribución de prueba geométrica. La pirámide de prueba de Noah nos facilita pensar en la mejor prueba para un problema específico que pueda ocurrir.
Es mejor tener una prueba para su propósito que solo una Cobertura de prueba Como meta. Ayuda a crear pruebas que realmente agregan valor.
Cobertura de prueba Solo indica qué líneas de código de producción se ejecutaron durante la ejecución de la prueba, nada más. Veremos esto en el siguiente ejemplo:
Esta es una clase para validar nombres. Hay algunas reglas, si el nombre es válido o inválido, devolverá verdadero o falso.
Esta es la prueba unitaria:
Cuando se ejecuta una herramienta de cobertura como jacoco para generar un informe de la clase NameValidator, se mostrará La prueba cubre el 100% de este códigoPor lo tanto, alguien puede preguntar «¿Significa esto calidad?». la respuesta es: no completamente.
Tenga en cuenta que esta verificación de nombre no se ha completado por completo. Cuando se llama a la función «isValid» con la siguiente cadena, la clase NameValidator devolverá verdadero, que en realidad no representa el nombre real:
«123», «John Doe # 1984», «Michael Jordan 🐐».
Las cadenas que contienen números, caracteres especiales o emoji pasarán la verificación que devuelve verdadero y cuando no debería. No se implementa ningún código para garantizar que esta situación no sea válida. Aun así, el informe de cobertura de la prueba dirá que está cubierto al 100%.
Esta es la razón por La cobertura de la prueba no expresa con precisión la calidad.
Es por eso que usar la pirámide de prueba (o cualquier otra forma geométrica) como filtro de error puede ayudarnos a enfocarnos en Casos de prueba y posibles puntos de falla En lugar de probar la cobertura. Se trata de perspectiva.
