Les tests instrumentés Android
Les tests Android dits « instrumentés » sont des tests d’intégration ou des tests de bout-en-bout qui interagissent avec la plateforme Android. En tant que tels, ils vont s’exécuter en général sur un émulateur (c’est-à-dire un Android Virtual Device, ou AVD). Ce post explique comment utiliser adb pour lancer des tests instrumentés Android sur un AVD. Il est également possible de les exécuter sur un téléphone physique, mais on ne va pas détailler cette méthode.
L’IDE Android Studio permet bien sûr de lancer les tests depuis son interface graphique. Mais,il est aussi possible de les lancer indépendemment de l’IDE en ligne de commande. Cette utilisation se rapproche du mode d’exécution des tests dans une chaîne CI/CD.
Cet article va présenter comment exécuter manuellement les tests instrumentés en CLI. Cela se fait avec l’outil Android Debug Bridge (ADB) shell et un émulateur AVD (Android Virtual Device).
ADB est un outil qui est composé de 3 processus séparés. Un daemon (adbd) qui tourne sur le device (émulé ou réel), un client, et un serveur. Ces derniers tournent sur la plateforme de test (l’ordinateur où est Android Studio ou serveur Jenkins par exemple). Quand Android Studio est installé, ces éléments sont installés par l’IDE, et démarrés quand l’AVD est démarré.
ADB permet de faire bien plus que juste lancer des tests, voir la documentation de Google ici : https://developer.android.com/studio/command-line/adb
On va donc voir en détails comment utiliser adb pour lancer des tests instrumentés d’un projet quelconque.
Voici les étapes:
- Avoir un projet Android contenant des tests instrumentés
- Savoir comment lancer adb
- Démarrer un AVD et installer le code projet dessus
- Vérifier que tout est démarré
- Obtenir le nom du Runner et du package à utiliser pour lancer les tests
- Lancer tous les tests
- Lancer une classe de tests unique
Préparatifs: projet de démo avec des tests instrumentés Android
Pour illustrer, j’utilise un projet public existant avec des tests instrumentés déjà codés.
L’exemple de projet que j’utilise provient de Google. Il illustre un Codelab sur les divers modes de tests d’Android.
Github: https://github.com/googlecodelabs/android-testing/tree/end_codelab_3
Il faut utiliser la branche « end_codelab_3 » de ce repository pour avoir des tests instumentés utilisables.
Pour commencer, importez ce projet dans Android Studio et démarrez un émulateur (version SDK minimale 21) dans l’AVD Manager d’Android Studio. L’AVD doit être démarré pour qu’adb puisse s’y connecter. On peut utiliser Android Studio pour faire ces étapes facilement. C’est également possible d’utiliser l’outil ’emulator’ pour les faire via CLI.
Comment lancer adb en ligne de commande
Pour trouver où Android Studio a enregistré l’outil adb sur votre machine, la commande find (sur Linux/Mac) suivante devrait vous renseigner.
Une fois localisé, le plus simple est de d’ajouter l’outil adb à votre PATH (comme illustré ci-dessous). Alternativement, vous pouvez lancer les commandes depuis le répertoire où elles se trouvent, ou utiliser le chemin absolu de la commande.
On peut faire une petite vérification en appelant adb pour afficher sa version, et on est prêts.
Démarrer un AVD (Android émulé)
A ce stade, il faut avoir démarré Android Studio et lancé un émulateur avec AVD Manager, comme décrit précédemment. On utilise l’application de notre projet-démo dont on sait qu’il comporte des tests instrumentés.
Commandes utiles et vérifications
Dans tous les exemples de commandes suivants, on utilise adb avec un device émulé (AVD). Pour utiliser un device réel, il faudrait ajouter l’option ‘-d‘ aux commandes adb. L’option par défaut est l’émulateur, qu’on peut aussi préciser explicitement avec l’option ‘-e‘.
Une fois que l’AVD est démarré, on peut utiliser adb pour voir les systèmes Android connectés. Normalement l’émulateur devrait apparaître dans la liste résultante une fois qu’il est complètement démarré.
Pour le cas où vous avez plusieurs émulateurs démarrés simultannément, on peut préciser à adb le device spécifique à utiliser avec une option « serial number », au format ‘-s emulator-5554‘ dans mon exemple. Le serial number est la valeur donnée par la commande devices.
Identifier le package Android et le Runner
Il est possible de vérifier que notre code de test est bien déployé sur l’émulateur en recherchant avec adb et le package manager (pm) la liste des instrumentaions disponibles.
On devrait aussi voir que l' »instrumentation » pour démarrer les tests instrumentées est bien installée sur l’émulateur. Si ce n’est pas le cas, tenter de lancer les tests instrumentés via Android Studio (en faisant Run sur une classes de tests dans le groupe « androidTests » du projet). Il est aussi possible de le déployer en CLI avec adb ou la tâche gradle du plugin Android installDebugAndroidTest.
Les valeurs affichées pour l’instrumentation donnent le nom du Runner et du package Android à utiliser pour lancer les tests.
Runner: ‘androidx.test.runner.AndroidJUnitRunner’
Package Android : ‘com.example.android.architecture.blueprints.reactive.test’
Une autre commande utile pour vérifier l’état de l’émulateur via le package manager (pm). Celle-ci permet de voir les packages Android installés sur le device, au cas où on ne retrouve pas directement celui qui nous intéresse dans les instrumentations. On peut filtrer pour plus de lisibilité en précisant :
- activés: ‘-e‘ pour enabled,
- de type « 3rd party » (ie non-système):’-3‘
- filtrer sur un mot dans le nom du package Android, ici ‘architecture‘
Voici la commande pour voir les packages Android filtrés:
Si le package voulu n’est pas installé, à défaut de lancer les tests une fois via Android Studio, on peut utiliser le build script Gradle du projet pour exécuter la task ‘installDebugAndroidTest‘ avec le wrapper gradlew du projet, ou à défaut avec la commande gradle.
Exécuter tous les tests instrumentés
Aprés toute cette préparation, il est temps de lancer les tests. On utilise les paramètres découverts précédemment pour le Runner et le nom de package dans la commande suivante. Cela se fait via l’activity manager (am). L’option ‘-w‘ (wait) force adb à attendre la fin du process de l’instrumentation, pour voir les résultats des tests.
Exécuter une classe de tests particulière
En bonus, si on veut préciser une classe de tests particulière et limiter le logs, on pourra ajouter des options String « en extra » au format ‘-e <clé> <valeur>‘ pour définir une valeur de la clé ‘debug‘ et de la clé ‘class‘, en donnant un nom de class complet avec son package Java.
Evolution du Runner de tests AndroidJUnitRunner
Attention, à noter que la documentation de Google sur les tests en CLI contenait des éléments non mis à jour, en particulier le Test Runner a changé de package Java. A l’origine AndroidJUnitRunner était dans un autre namespace, la documentation Android actuelle l’indique encore avec l’ancien nom, ce qui ne fonctionnera pas avec du code récent.
- ancien : android.support.test.runner.AndroidJUnitRunner
- actuel (septembre 2021) : androidx.test.runner.AndroidJUnitRunner
