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. Des exemples typiques peuvent inclure :

  • installer d'autres apks (en plus de l'apk de test)
  • transférer 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écessite une compréhension du fonctionnement de la Fédération du commerce 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 des tâches courantes ci-dessus peut être réalisée par quelques lignes de configuration seulement. 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 faisceau d'automatisation des tests de la Trade Federation. Actuellement, les principales balises gérées via les configurations du module de test sont les balises «target_preparer» et «test».

Cibler les préparateurs

Une balise «target_preparer», comme son nom l'indique, définit un préparateur cible (voir ITargetPreparer ) qui propose une méthode de configuration, qui est appelée avant que le module de test ne soit exécuté pour les tests ; 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 commune du module intégré, 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>

A 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 faisceau de test pour :

  1. avant que le module de test ne soit invoqué, exécutez la commande shell « settings put secure attachment_enabled 1 » sur l'appareil
  2. une fois le module de test terminé, exécutez la commande shell « settings put secure attachment_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 manière 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 : fichier push
    • fonction : pousse les fichiers arbitraires du dossier du scénario de test vers la destination sur l'appareil
    • Remarques :
      • ce préparateur peut passer d'un dossier à l'autre ou d'un fichier à l'autre ; c'est-à-dire que vous ne pouvez pas placer un fichier dans 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, spécifiant le fichier local sur le chemin où il doit être poussé sur le périphérique. 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, 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 : une commande à exécuter sur l'appareil (avec ` adb shell <your command> `) une fois que tous les push ont été tentés. Un cas d'utilisation typique serait d'utiliser chmod pour les autorisations
  • nom de classe : InstallApkSetup

    • nom court : install-apk
    • fonction : pousse les 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 un tiret de début, par exemple "-d". Peut être répété
  • nom de 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 adb shell à exécuter pendant la phase de démontage. Peut être répété

Classe d'essai

Une classe de test est la classe de la Fédération commerciale à 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 tests 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 tests d'instrumentation sur un appareil donné
    • choix :
      • package : nom du package manifeste de l’application de test Android à exécuter.
      • class : Le nom de la classe de test à exécuter.
      • method : Le nom de la méthode de test à exécuter.
  • nom de la classe : AndroidJUnitTest

    • function : un 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.