Configuration de test complexe

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 courants:

  • installer d'autres APK (en plus de l'APK test) ;
  • transférer des fichiers vers l'appareil ;
  • exécuter des commandes (par exemple, adb shell pm ...) ;

Auparavant, les équipes de composants recouraient généralement à l'écriture d'un test côté hôte pour effectuer ces tâches, ce qui nécessite une compréhension du harnais Trade Federation et augmente généralement la complexité d'un module de test .

En empruntant CTS, nous avons introduit le concept de configuration de module de test pour prendre en charge de telles tâches. La liste de tâches courantes ci-dessus peut être obtenue en quelques lignes de configuration seulement. 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.

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 de la Trade Federation. Actuellement, les balises principales gérées via 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, qui est appelée avant l'exécution du module de test à des fins de test. 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 commune intégrée, ajoutez un fichier "AndroidTest.xml" dans le dossier de niveau supérieur de votre module de test, puis 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 configurent le banc d'essais pour:

  1. Avant l'appel du module de test, exécutez la commande shell "settings put secure accessibility_enabled 1" sur l'appareil.
  2. 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. Après avoir présenté un exemple simple, il est nécessaire d'expliquer plus en détail comment la balise "option" est utilisée. Comme indiqué ci-dessus, la balise peut avoir deux attributs: nom et 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 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 de 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 dans le dossier du 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 dans un dossier de l'appareil: vous devez également spécifier le nom de fichier de destination dans ce dossier.
    • options :
      • push-file:spécification de transfert, qui indique le fichier local au 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 peut être relatif au répertoire du module de test ou au répertoire "out" 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. Un cas d'utilisation courant consiste à utiliser chmod pour les autorisations.

  • nom de la classe: InstallApkSetup

    • nom court:install-apk
    • function:envoie des fichiers APK arbitraires 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 initial, par exemple "-d". Peut être répété

  • Nom de la classe: RunCommandTargetPreparer

    • Nom court:run-command
    • function:exécute des commandes shell arbitraires avant ou après l'exécution du module de test
    • options:
      • 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 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
    • 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

    • nom court: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 un appareil donné à l'aide d'android.support.test.runner.AndroidJUnitRunner. Il s'agit du principal moyen d'exécuter un test d'instrumentation.