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 cas de test lui-même. Des exemples typiques peuvent inclure :
- installer d'autres apks (en plus de l'apk de test)
- pousser certains fichiers sur 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écessitait une compréhension du harnais de la fédération commerciale et augmentait généralement la complexité d'un module de test.
Empruntant à 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 cible, tel que défini par ITargetPreparer ou ITargetCleaner , et les configurer pour les utiliser dans votre propre configuration de module de test.
Une configuration de module de test pour un module de test est un fichier XML requis ajouté au dossier source du module de niveau supérieur, nommé « AndroidTest.xml ». Le XML suit le format d'un fichier de configuration utilisé par le harnais d'automatisation des tests de la Fédération commerciale. Actuellement, les principales balises gérées via les configurations du module de test sont les balises "target_preparer" et "test".
Préparateurs cibles
Une balise « target_preparer », comme son nom l'indique, définit un préparateur cible (voir ITargetPreparer ) qui offre une méthode de configuration, qui est appelée avant que le module de test ne soit exécuté pour le test ; et si la classe référencée dans la balise "target_preparer" implémente également ITargetCleaner , sa méthode de démontage sera invoquée une fois le module de test terminé.
Pour utiliser la configuration de module commune intégrée, ajoutez un nouveau fichier "AndroidTest.xml" dans le 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>
À titre d'exemple, nous pouvons ajouter les balises d'option suivantes (au niveau du commentaire "insérer" 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 l'appel du module de test, exécutez la commande shell "settings put secureaccessibility_enabled 1" sur l'appareil
- une fois le module de test terminé, exécutez la commande shell "settings put secureaccessibility_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. Avec un exemple simple démontré, il est nécessaire de couvrir plus de détails sur la façon dont la balise "option" est utilisée. Comme indiqué ci-dessus, la balise peut avoir deux attributs : nom, valeur. 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'un booléen ou même d'un chemin de fichier. Voici un résumé des trois préparateurs cibles courants :
nom de la classe : PushFilePreparer
- nom court : push-file
- fonction : pousse les fichiers arbitraires sous le dossier de cas de test vers la destination sur l'appareil
- remarques :
- ce préparateur peut pousser d'un dossier à l'autre ou d'un fichier à l'autre ; c'est-à-dire que vous ne pouvez pas pousser un fichier sous un dossier sur l'appareil : vous devez également spécifier le nom du fichier de destination sous ce dossier
- option :
- push-file : une spécification push, spécifiant le fichier local dans le chemin où il doit être poussé sur l'appareil. Peut être répété. Si plusieurs fichiers sont configurés pour être poussés vers le même chemin distant, le dernier sera poussé.
- push : (obsolète) Une 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é. Ce chemin peut être relatif au répertoire du module de test ou au répertoire de sortie lui-même. - post-push : une commande à exécuter sur l'appareil (avec `
adb shell <your command>`) après que toutes les tentatives de poussée ont été tentées. Le cas d'utilisation typique serait d'utiliser chmod pour les autorisations
nom de la classe : InstallApkSetup
- nom court : install-apk
- fonction : pousse des fichiers apk arbitraires vers la destination sur l'appareil
- choix :
- test-file-name : le nom de l'apk à installer sur l'appareil.
- install-arg : arguments supplémentaires à transmettre à la commande pm install, y compris le tiret initial, par exemple "-d". Peut être répété
nom de la classe : RunCommandTargetPreparer
- nom court : commande d'exécution
- fonction : exécute des commandes shell arbitraires avant ou après l'exécution du module de test
- choix :
- run-command : commande shell adb à exécuter. Peut être répété
- teardown-command : commande shell adb à exécuter pendant la phase de démontage. Peut être répété
Classe d'essai
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 : un test qui exécute un package de test natif sur un appareil donné.
- choix :
- native-test-device-path : chemin sur l'appareil où se trouvent les tests natifs.
nom de la classe : InstrumentationTest
- nom court : instrumentation
- fonction : un test qui exécute un package de test d'instrumentation sur un appareil donné
- choix :
- package : nom du package de manifeste de l'application de test Android à exécuter.
- class : le nom de la classe de test à exécuter.
- method : nom de la méthode de test à exécuter.
nom de la classe : AndroidJUnitTest
- fonction : un test qui exécute un package de test d'instrumentation sur un appareil donné à l'aide de android.support.test.runner.AndroidJUnitRunner. C'est le principal moyen d'exécuter un test d'instrumentation.