El artículo se publica en nombre de Andrey Ivanov y Ekaterina Bateeva , neifmetus.
La automatización de aplicaciones móviles es un área bastante joven: hay muchos marcos y muchos proyectos se enfrentan con el problema de elegir el más “rápido, estable y fácil de usar”. Hace aproximadamente dos años, también nos enfrentamos a la elección de una nueva herramienta de automatización para probar aplicaciones de Android.
Todas las herramientas populares se basaban de alguna manera en UIAutomator y Espresso, por lo que decidimos probarlas en su forma pura y compararlas con el mismo Appium (el más popular) y
seeTest (utilizado antes, el mejor entre los pagos en ese momento).
De las ventajas de Appium, se puede distinguir la API WebDriver habitual, la capacidad de usar los idiomas y bibliotecas más populares. Además, es ampliamente utilizado en muchas compañías y le permite escribir pruebas directamente para plataformas iOS y Android. Y finalmente, esta es una solución gratuita en caja: ¿qué podría ser mejor?
Entonces pensamos, hasta que descubrimos las siguientes deficiencias:
- baja estabilidad del servidor Appium
- No puede interactuar con los métodos públicos de Actividad (en 2018, Nikolai Abalov de Badoo habló sobre la creación de una puerta trasera en Appium en su artículo, puede leer aquí )
- muy inferior en velocidad de pruebas de Espresso
Para nosotros, estos momentos fueron críticos, por lo que se decidió reunir nuestro propio conjunto de herramientas en torno a Espresso para construir un ecosistema para probar aplicaciones móviles.
Entonces, el marco fue seleccionado, quedaba por encontrar los componentes restantes:
- Runner : debe permitir ejecutar pruebas en paralelo y configurar grupos de dispositivos
- Reportero : debe proporcionar un informe legible que pueda ser utilizado por cualquier miembro del equipo
Las herramientas
Con el corredor, todo estuvo bien, un poco de excavación en github, se eligió
shazam / fork .
Le permite configurar convenientemente el conjunto de dispositivos, fácil de modificar, genera un informe html simple. Logcat se aplica a cada informe, en el caso de una prueba de stacktrace y un bloqueo de video. La grabación de video no funciona correctamente, todos los videos duran 1 minuto, a veces se graban varias pruebas en el video.
Los informes de fork estaban lejos de ser ideales, el usuario final no entendía lo que estaba sucediendo en la prueba solo por su nombre, sin tener un caso de prueba a la mano. Quería tener pasos con archivos adjuntos que me permitieran estructurar el informe. La búsqueda de un reportero para las pruebas de instrumentación arrojó 2 variantes de cuchara y pepino. Ambas opciones se descartaron porque un montón de capturas de pantalla en el caso de cuchara y bdd del pepino no resolvieron el problema por completo ...
Allure parecía la solución más óptima para el problema:
- anidación de pasos que le permite estructurar el informe
- la capacidad de grabar datos de prueba personalizados (capturas de pantalla, video, número de tarea, parámetros de prueba)
- vista concisa del informe
Pero hubo una advertencia, Allure simplemente no se inicia en Android.
Allure-android
En relación con lo anterior, se decidió escribir una biblioteca que combina la simplicidad y elegancia de Kotlin, las ventajas del marco Allure y puede funcionar en teléfonos Android. Para conectar la biblioteca, agregue dependencias al módulo en el que se encuentran las pruebas de instrumentación:
dependencies { androidTestImplementation "ru.tinkoff.allure:allure-android:$allureVersion@aar" androidTestImplementation "ru.tinkoff.allure:allure-common:$allureVersion" androidTestImplementation "ru.tinkoff.allure:allure-model:$allureVersion" }
Después de configurar las dependencias, debemos registrar
AllureRunListener en la clase responsable de ejecutar las pruebas de Android.
Hay tres formas de hacer esto:
- Añadir a build.gradle
testInstrumentationRunner "ru.tinkoff.allure.android.AllureAndroidRunner"
- Agregar escucha a los argumentos en Runner onCreate (argumentos: paquete)
arguments.putCharSequence("listener", AllureAndroidListener::class.java.name)
- Directamente heredado de AllureAndroidRunner
Los informes de Allure se basan en el paso: un paso, una acción atómica que se realiza durante una prueba. Las anotaciones del marco Allure
Step y
Parameter han sido reemplazadas por una llamada directa a la función step ().
inline fun <T : Any?> step(description: String, vararg params: Parameter, block: () -> T): T
Esta función no solo reemplaza dos anotaciones a la vez, sino que también acepta una lambda en la que debe ajustar la lógica de prueba. Por ejemplo:
Después de comenzar la prueba, los informes en formato json preparados para Allure2 aparecerán en el teléfono en la carpeta / sdcard / allure-results. Sacando el resultado por
adb pull /sdcard/allure-results
podemos generar un informe
allure generate
De las características adicionales, podemos distinguir:
- la capacidad de invertir pasos unos en otros
- en cualquier lugar, puede llamar a deviceScreenshot (tag: String) para tomar una captura de pantalla que se adjuntará automáticamente al informe en el paso actual
- FailshotRule () - Junit4 Rule, tomará una captura de pantalla justo antes de la caída
Esta es una descripción general del uso de Allure en la plataforma Android. La solución allure-android está disponible en
GitHub , puedes verla en detalle y participar en el desarrollo.