La structure globale de la configuration du module suit un modèle semblable à la configuration XML Tradefed standard, mais avec quelques restrictions dues au fait qu'ils s'exécutent dans le cadre d'une suite.
Liste des balises autorisées
AndroidTest.xml ou plus généralement, la configuration de module 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 section Configuration XML modifiée si vous avez besoin d'un rappel sur les différentes balises.
Les objets tels que build_provider ou result_reporter génèrent une erreur ConfigurationException si vous tentez d'exécuter ces actions à partir d'une configuration de module. Cela permet d'éviter que ces objets effectuent réellement une tâche dans un module.
Exemple de configuration du module
<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 qui exécute une instrumentation sur le package android.gesture.cts.
Balises d'inclusion <include> et <template-include>
L'utilisation de <include> et <template-include> dans les configurations de module est déconseillée. Il n'est pas garanti qu'elles fonctionnent comme prévu.
Cas particulier pour la balise metrics_collector
metrics_collector est autorisé, mais limité à la classe FilePullerLogCollector afin de spécifier un fichier ou un répertoire donné à extraire et enregistrer pour le module. Cette option est utile si vous laissez des journaux à 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 compilation ou des téléchargements ?
La définition des tags autorisés peut donner l'impression incorrecte qu'un module ne recevra aucune information sur la compilation. C'est faux.
Les informations sur la compilation 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 configuration de premier niveau unique pour la suite afin d'exécuter tous les modules de la suite.
Par exemple, au lieu que chaque module de la suite de tests de compatibilité (CTS) interroge individuellement les informations, les types, etc. des appareils, la configuration au niveau de la suite CTS (cts.xml) l'effectue une seule fois, et chaque module recevra ces informations s'il les demande.
Pour que les objets d'un module reçoivent les informations de compilation, ils doivent procéder de la même manière que dans la configuration Tradefed standard: implémenter l'interface IBuildReceiver pour recevoir le IBuildInfo. Pour en savoir plus, consultez la section Tests avec un appareil.
Champs de métadonnées
Un grand nombre de modules de test incluent des spécifications 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" />
Component
Les métadonnées component décrivent le composant Android général que le module a l'intention de tester. Il n'a pas d'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 en présoumission si un composant inexistant est ajouté à un module CTS.
Vous pouvez filtrer une exécution de suite en fonction des composants à l'aide de module-metadata-include-filter et module-metadata-exclude-filter.
Exemple :
--module-metadata-include-filter component framework
Cet exemple n'exécute que le module de test annoté avec le composant framework.
Paramètre
Les métadonnées parameter sont informatives et ont une incidence sur l'exécution du test. Il spécifie le mode Android auquel le module de test s'applique.
Dans ce cas, les modes sont limités aux modes Android de haut niveau, tels que instant apps, secondary users ou 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 dans des modes différents.
instant_app: créez une variante des tests qui installent des APK en tant qu'applications instantanées.multi_abi: créez une variante des tests pour chaque ABI compatible avec l'appareil.secondary_user: créez une variante des tests qui installent des APK et exécutent des tests en tant qu'utilisateur secondaire.
Collecte et post-traitement des métriques pour les modules de test de performances
Pour les modules de test de performances, les metrics_collector et metric_post_processor au niveau du module sont autorisés, car ils sont essentiels aux tests de performances.
Les collecteurs de métriques et les post-traiteurs au niveau du module peuvent être spécifiques au module.
Il est déconseillé de spécifier des post-processeurs au niveau supérieur et au niveau du module.
Une configuration de module de test de performances doit inclure les métadonnées test-type avec la valeur performance, comme suit :
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Sans cela, si une configuration de test inclut un metric_collector autre que FilePullerLogCollector ou un metric_post_processor, le test échoue lors de la présoumission.
Exemple de configuration du module de test de performances:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>