Structure AndroidTest.xml

La structure globale de la configuration du module suit un schéma similaire à la configuration XML habituelle de Tradefed, mais avec certaines restrictions dues au fait qu'ils s'exécutent dans le cadre d'une suite.

Liste des balises autorisées

La configuration du module AndroidTest.xml ou plus généralement ne peut contenir que les balises XML suivantes : target_preparer , multi_target_preparer , test et metrics_collector .

Bien que cette liste semble restrictive, elle vous permet de définir précisément les besoins de configuration du module de test et le test à exécuter.

REMARQUE : Consultez la configuration XML de Tradefed si vous avez besoin d'un rappel sur les différentes balises.

Des objets tels que build_provider ou result_reporter une ConfigurationException s'ils tentent d'être exécutés depuis l'intérieur d'une configuration de module. Ceci est destiné à éviter que l'on s'attende à ce que ces objets effectuent réellement une tâche à partir d'un module.

Exemple de configuration de modules

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />
    </test>
</configuration>

Cette configuration décrit un test qui nécessite l'installation de CtsGestureTestCases.apk et exécutera une instrumentation sur le package android.gesture.cts .

Cas particulier de la balise "metrics_collector"

Le metrics_collector est autorisé mais limité à la classe FilePullerLogCollector afin de spécifier un fichier ou un répertoire donné à extraire et à journaliser pour le module. Ceci est utile si vous laissez des journaux dans un emplacement particulier et que vous souhaitez les récupérer automatiquement.

Exemple de configuration :

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

Qu'en est-il des informations de construction ou des téléchargements ?

La définition des balises autorisées peut donner l'impression erronée qu'un module n'obtiendra aucune information de construction. Ce n'est pas vrai .

Les informations de construction sont fournies à partir de la configuration au niveau de la suite et seront partagées par tous les modules de la suite. Cela permet une seule configuration de haut niveau pour la suite afin d'exécuter tous les modules faisant partie de la suite.

Par exemple, au lieu que chaque module CTS (Compatibility Test Suite) demande individuellement les informations sur les appareils, les types, etc., la configuration au niveau de la suite CTS ( cts.xml ) le fait une fois et chaque module recevra ces informations s'il le demande.

Pour que les objets d'un module reçoivent les informations de construction, ils doivent faire la même chose que dans la configuration habituelle de Tradefed : implémentez l'interface IBuildReceiver pour recevoir le IBuildInfo . Voir test avec appareil pour plus de détails.

Champs de métadonnées

Un grand nombre de modules de test incluent des spécifications de metadata , qui ont chacune un objectif unique.

Exemple:

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

Composant

Les métadonnées du component décrivent le composant Android général que le module a l'intention de tester. Cela n'a aucun impact direct sur l'exécution du test ; il est principalement utilisé à des fins organisationnelles.

La liste à jour des composants autorisés pour CTS est disponible dans CtsConfigLoadingTest . Ce test échoue lors de la pré-soumission si un composant inexistant est ajouté à un module CTS.

Vous pouvez filtrer l'exécution d'une suite en fonction des composants à l'aide module-metadata-include-filter et module-metadata-exclude-filter .

Exemple:

  --module-metadata-include-filter component framework

Cet exemple exécute uniquement le module de test annoté avec le composant framework .

Paramètre

Les métadonnées du parameter sont informatives et ont un impact sur l'exécution du test. Il spécifie à quel mode Android le module de test s'applique. Dans ce cas, les modes sont limités aux modes Android de haut niveau, tels que les instant apps , secondary users ou les different abis .

Lors de l'exécution de la suite, si le mode s'applique au test, plusieurs variantes du module de test sont créées en fonction du mode. Chaque variante exécute des tests similaires mais sous des modes différents.

  • instant_app : créez une variante des tests qui installent les APK en tant qu'applications instantanées.
  • multi_abi : Créer une variation des tests pour chaque ABI pris en charge par l'appareil.
  • secondary_user : créez une variante des tests qui installent les APK et exécutent les tests en tant qu'utilisateur secondaire.