Certains modules de test peuvent nécessiter des étapes de configuration et de suppression personnalisées qui ne peuvent pas être effectuées dans le scénario de test lui-même. Voici quelques exemples courants :
- installer d'autres APK (en plus de l'APK de test)
- transférer des fichiers vers l'appareil
- exécuter des commandes (par exemple, adb shell pm ...)
Auparavant, les équipes de composants avaient généralement recours à l'écriture d'un test côté hôte pour effectuer ces tâches, ce qui nécessitait de comprendre le harnais Trade Federation et augmentait généralement la complexité d'un module de test .
En nous inspirant de la suite de tests de compatibilité Android, nous avons introduit le concept de configuration de module de test pour prendre en charge ces tâches. La liste des tâches courantes ci-dessus peut être réalisée avec seulement quelques lignes de configuration. Pour une flexibilité maximale, vous pouvez même implémenter votre propre préparateur de cible, tel que défini par ITargetPreparer ou ITargetCleaner, et le configurer pour l'utiliser dans votre propre configuration de module de test.
Une configuration de module de test pour un module de test est un fichier XML obligatoire ajouté au dossier source du module de niveau supérieur, nommé "AndroidTest.xml". Le fichier XML suit le format d'un fichier de configuration utilisé par le harnais d'automatisation des tests Trade Federation. Actuellement, les principaux tags gérés via les configurations de module de test sont les tags "target_preparer" et "test".
Préparateurs de cible
Comme son nom l'indique, un tag "target_preparer" définit un préparateur de cible (voir ITargetPreparer) qui propose une méthode de configuration, appelée avant l'exécution du module de test pour le test. Si la classe référencée dans le tag "target_preparer" implémente également ITargetCleaner, sa méthode de suppression est appelée une fois le module de test terminé.
Pour utiliser la configuration de module commun intégrée, ajoutez un fichier "AndroidTest.xml" au dossier de niveau supérieur de votre module de test et remplissez-le avec le contenu suivant :
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
Par exemple, nous pouvons ajouter les tags d'option suivants (au commentaire "insert" ci-dessus) :
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put secure accessibility_enabled 1" />
<option name="teardown-command" value="settings put secure accessibility_enabled 0" />
</target_preparer>
Les options configurent le harnais de test comme suit :
- Avant l'appel du module de test, exécutez la commande shell "settings put secure accessibility_enabled 1" sur l'appareil.
- Une fois le module de test terminé, exécutez la commande shell "settings put secure accessibility_enabled 0".
Dans cet exemple particulier, l'accessibilité est activée/désactivée respectivement avant/après l'exécution du module de test. Maintenant que nous avons vu un exemple simple, nous devons aborder plus en détail l'utilisation du tag "option". Comme indiqué ci-dessus, le tag peut comporter deux attributs : name et value. L'attribut name doit faire référence à l'une des options proposées par le préparateur.
L'objectif exact du champ value dépend de la manière dont le préparateur a défini l'option : il peut s'agir d'une chaîne, d'un nombre, d'une valeur booléenne ou même d'un chemin d'accès à un fichier. Voici un résumé des trois préparateurs de cible courants :
Nom de la classe : PushFilePreparer
- Nom court : push-file
- Fonction : transfère des fichiers arbitraires sous le dossier de scénario de test vers la destination sur l'appareil
- Remarques:
- Ce préparateur peut transférer des fichiers d'un dossier à un autre ou d'un fichier à un autre. Autrement dit, vous ne pouvez pas transférer un fichier sous un dossier sur l'appareil : vous devez également spécifier le nom de fichier de destination sous ce dossier.
- Options:
- push-file : spécification de transfert, indiquant le fichier local vers le chemin d'accès où il doit être transféré sur l'appareil. Peut être répété. Si plusieurs fichiers sont configurés pour être transférés vers le même chemin d'accès distant, le dernier sera transféré.
- push : (obsolète) spécification de transfert, au format
'
/path/to/srcfile.txt->/path/to/destfile.txt' ou '/path/to/srcfile.txt->/path/to/destdir/'. Peut être répété. Ce chemin d'accès peut être relatif au répertoire du module de test ou au répertoire de sortie lui-même. - post-push : commande à exécuter sur l'appareil (avec `
adb shell <your command>`) une fois toutes les tentatives de transfert effectuées. Le cas d'utilisation typique consiste à utiliser chmod pour les autorisations.
Nom de la classe : InstallApkSetup
- Nom court : install-apk
- Fonction : transfère des fichiers APK arbitraires sous vers la destination sur l'appareil
- Options
- test-file-name : nom de l'APK à installer sur l'appareil.
- install-arg : arguments supplémentaires à transmettre à la commande pm install, y compris le tiret de début, par exemple "-d". Peut être répété
Nom de la classe : RunCommandTargetPreparer
- Nom court : run-command
- Fonction : exécute des commandes shell arbitraires avant ou après l'exécution du module de test
- Options
- run-command : commande adb shell à exécuter. Peut être répété
- teardown-command : commande adb shell à exécuter pendant la phase de suppression. Peut être répété
Classe de test
Une classe de test est la classe Trade Federation à utiliser pour exécuter le test.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="android.test.example.helloworld"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
Voici trois classes de test courantes :
Nom de la classe : GTest
- Nom court : gtest
- Fonction : test qui exécute un package de test natif sur un appareil donné.
- Options
- native-test-device-path: Chemin d'accès sur l'appareil où se trouvent les tests natifs.
Nom de la classe : InstrumentationTest
- Nom court : instrumentation
- Fonction : test qui exécute un package de test d'instrumentation sur un appareil donné
- Options
- package: nom du package du manifeste de l'application de test Android à exécuter.
- class : nom de la classe de test à exécuter.
- method : nom de la méthode de test à exécuter.
Nom de la classe : AndroidJUnitTest
- Fonction : test qui exécute un package de test d'instrumentation sur un appareil donné à l'aide de android.support.test.runner.AndroidJUnitRunner. Il s'agit du principal moyen d'exécuter un test d'instrumentation.