Certains modules de test peuvent nécessiter des étapes de configuration et de démontage personnalisées qui ne peuvent pas être effectuées dans le scénario de test lui-même. Voici quelques exemples typiques :
- 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 …) ;
Dans le passé, les équipes de composants avaient généralement recours à l'écriture d'un test côté hôte pour effectuer de telles tâches, ce qui nécessite de comprendre le harnais Trade Federation et augmente généralement la complexité d'un module de test .
En nous inspirant du CTS, nous avons introduit le concept de configuration de module de test pour prendre en charge de telles tâches. La liste des tâches courantes ci-dessus peut être réalisée en 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 les configurer pour les utiliser dans votre propre configuration de module de test.
Un fichier XML obligatoire nommé "AndroidTest.xml" doit être ajouté au dossier source du module de premier niveau. Il suit le format d'un fichier de configuration utilisé par le harnais d'automatisation des tests Trade Federation. Actuellement, les balises principales gérées par les configurations du module de test sont les balises "target_preparer" et "test".
Préparateurs cibles
Comme son nom l'indique, une balise "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 les tests. Si la classe référencée dans la balise "target_preparer" implémente également ITargetCleaner, sa méthode de démontage sera 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 premier niveau 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 balises d'option suivantes (au niveau du 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 configureront le harnais de test pour :
- Avant d'appeler le 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 avant/après l'exécution du module de test, respectivement. Maintenant que nous avons vu un exemple simple, il est nécessaire d'aborder plus en détail l'utilisation de la balise "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 de valeur dépend de la façon 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 cibles courants :
Nom de la classe : PushFilePreparer
- short name : push-file
- function : envoie des fichiers arbitraires du dossier de scénario de test vers la destination sur l'appareil
- notes :
- Ce préparateur peut transférer des fichiers de dossier à dossier ou de fichier à fichier. En d'autres termes, vous ne pouvez pas transférer un fichier sous un dossier sur l'appareil : vous devez également spécifier le nom du fichier de destination sous ce dossier.
- options :
- push-file : une spécification push, qui indique le fichier local et 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 push, formatée comme "
/path/to/srcfile.txt->/path/to/destfile.txt" ou "/path/to/srcfile.txt->/path/to/destdir/". Peut être répétée. 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 que toutes les tentatives de transfert ont été effectuées. Un cas d'utilisation typique consiste à utiliser chmod pour les autorisations.
Nom de la classe : InstallApkSetup
- short name : install-apk
- function: pushes arbitrary apk files under into destination on device
- 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
- short name : run-command
- function : 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 abrégé : gtest
- function : 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
- short name : instrumentation
- function : test qui exécute un package de test d'instrumentation sur un appareil donné.
- options :
- package : nom du package 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
- function : test qui exécute un package de test d'instrumentation sur l'appareil donné à l'aide d'android.support.test.runner.AndroidJUnitRunner. Il s'agit de la principale méthode d'exécution d'un test d'instrumentation.