L'article est publié au nom d'Andrey Ivanov et Ekaterina Bateeva , neifmetus
L'automatisation des applications mobiles est un domaine assez récent: il existe de nombreux frameworks et de nombreux projets sont confrontés au problème de choisir le plus «rapide, stable, facile à utiliser». Il y a environ deux ans, nous avons également été confrontés au choix d'un nouvel outil d'automatisation pour tester les applications Android.
Tous les outils populaires étaient en quelque sorte basés sur UIAutomator et Espresso, nous avons donc décidé de les tester sous leur forme pure et de les comparer avec le même Appium (le plus populaire) et
seeTest (utilisé auparavant, le meilleur parmi ceux payés à l'époque).
Parmi les avantages d'Appium, on peut distinguer l'API WebDriver habituelle, la possibilité d'utiliser les langues et les bibliothèques les plus populaires. De plus, il est largement utilisé dans de nombreuses entreprises et vous permet d'écrire des tests directement pour les plateformes iOS et Android. Et enfin, il s'agit d'une solution gratuite en boîte - quoi de mieux?
Nous avons donc pensé, jusqu'à ce que nous découvrions les lacunes suivantes:
- faible stabilité d'Appium Server
- Vous ne pouvez pas interagir avec les méthodes publiques d'activité (en 2018, Nikolai Abalov de Badoo a parlé de créer une porte dérobée dans Appium dans son article, vous pouvez lire ici )
- très inférieure à la vitesse des tests Espresso
Pour nous, ces moments ont été critiques, il a donc été décidé de collecter notre propre ensemble d'outils autour d'Espresso pour construire un écosystème de test des applications mobiles.
Donc, le cadre a été sélectionné, il restait à trouver les composants restants:
- Runner - devrait permettre d'exécuter des tests en parallèle et de configurer des pools de périphériques
- Journaliste - doit fournir un rapport lisible pouvant être utilisé par n'importe quel membre de l'équipe
Les outils
Avec le coureur, tout allait bien, un peu de fouille sur github,
shazam / fork a été choisi.
Il vous permet de configurer facilement le pool d'appareils, facile à modifier, génère un simple rapport html. Logcat est appliqué à chaque rapport, en cas de test de stacktrace et de crash vidéo. L'enregistrement vidéo ne fonctionne pas correctement, toutes les vidéos durent 1 minute, parfois plusieurs tests sont enregistrés sur la vidéo.
Les rapports de fork étaient loin d'être idéaux, l'utilisateur final ne comprenait pas ce qui se passait dans le test uniquement par son nom, sans avoir un cas de test à portée de main. Je voulais avoir des étapes avec des pièces jointes qui me permettraient de structurer le rapport. La recherche d'un reporter pour les tests d'instrumentation a donné 2 variantes de cuillère et de concombre. Les deux options ont été rejetées car un tas de captures d'écran dans le cas de la cuillère et du bdd du concombre n'a pas résolu le problème complètement ...
Allure semblait la solution la plus optimale au problème:
- imbrication d'étapes qui vous permet de structurer le rapport
- la possibilité d'enregistrer des données de test personnalisées (captures d'écran, vidéo, numéro de tâche, paramètres de test)
- vue concise du rapport
Mais il y avait une mise en garde, Allure ne démarre tout simplement pas sur Android.
Allure-android
Dans le cadre de ce qui précède, il a été décidé d'écrire une bibliothèque qui combine la simplicité et l'élégance de Kotlin, les avantages du cadre Allure et peut fonctionner sur les téléphones Android. Afin de connecter la bibliothèque, ajoutez des dépendances au module dans lequel se trouvent les tests d'instrumentation:
dependencies { androidTestImplementation "ru.tinkoff.allure:allure-android:$allureVersion@aar" androidTestImplementation "ru.tinkoff.allure:allure-common:$allureVersion" androidTestImplementation "ru.tinkoff.allure:allure-model:$allureVersion" }
Après avoir configuré les dépendances, nous devons enregistrer
AllureRunListener à la classe responsable de l'exécution des tests Android.
Il existe trois façons de procéder:
- Ajouter à build.gradle
testInstrumentationRunner "ru.tinkoff.allure.android.AllureAndroidRunner"
- Ajouter un écouteur aux arguments dans Runner onCreate (arguments: Bundle)
arguments.putCharSequence("listener", AllureAndroidListener::class.java.name)
- Hérité directement d'AllureAndroidRunner
Les rapports Allure sont basés sur une étape - une étape, une action atomique qui est effectuée pendant un test.
Les annotations du cadre Allure
Step et
Parameter ont été remplacées par un appel direct à la fonction step ().
inline fun <T : Any?> step(description: String, vararg params: Parameter, block: () -> T): T
Cette fonction remplace non seulement deux annotations à la fois, mais accepte également un lambda dans lequel vous devez encapsuler la logique de test. Par exemple:
Après avoir commencé le test, les rapports au format json préparés pour Allure2 apparaîtront sur le téléphone dans le dossier / sdcard / allure-results. Extraire le résultat en
adb pull /sdcard/allure-results
nous pouvons générer un rapport
allure generate
Parmi les fonctionnalités supplémentaires, nous pouvons distinguer:
- la capacité d'investir des étapes les unes dans les autres
- n'importe où, vous pouvez appeler deviceScreenshot (tag: String) pour prendre une capture d'écran qui sera automatiquement jointe au rapport à l'étape en cours
- FailshotRule () - Junit4 Rule, prendra une capture d'écran juste avant la chute
Ceci est un aperçu de l'utilisation d'Allure sur la plate-forme Android. La solution allure-android est disponible sur
GitHub , vous pouvez voir en détail et participer au développement.