Passer les options et les filtres à la suite et aux modules, Passer les options et les filtres à la suite et aux modules

Tout d’abord, assurez-vous de bien comprendre la gestion des options dans Tradefed.

La configuration de la suite décrit les deux couches qui existent dans la structure de la suite :

  • La suite du haut niveau
  • Les modules

Dans un contexte Tradefed hors suite, il n’est pas nécessaire d’y penser ; chaque option va à l’invocation complète. Dans un contexte de suite, les modules restent isolés de la suite ; donc toutes les options ne sont pas disponibles à leur niveau.

Passer les options à la suite de niveau supérieur

La suite de niveau supérieur se comporte comme une configuration Tradefed standard : la configuration complète, y compris le coureur de suite, reçoit toutes les options comme une configuration Tradefed hors suite.

Passer les options aux modules

Les modules par défaut ne reçoivent aucune des options passées à la commande. Ils doivent être explicitement ciblés pour recevoir les options via l'option module-arg . Cette isolation des options des modules facilite le débogage.

Exemple:

cts-tradefed run cts --module-arg <module-name>:<option-name>:<option-value>

cts-tradefed run cts --module-arg CtsGestureTestCases:collect-tests-only:true

La syntaxe garantit que le module ciblé recevra l'option donnée.

Il existe des moyens supplémentaires pour transmettre des options aux modules tels que test-arg , qui vous permet de transmettre des options au programme d'exécution de test de chaque module en fonction du type ou de la classe du programme d'exécution.

Exemple:

cts-tradefed run cts --test-arg <test-class>:<option-name>:<option-value>

cts-tradefed run cts --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

La syntaxe ne cible pas un module particulier mais plutôt tous les lanceurs de tests de la classe donnée. test-arg ne considère que les implémentations de IRemoteTest comme récepteur potentiel des options.

Transmettre les options à une classe de test Java dans un java_test_host

Si vous ajoutez une @Option à votre classe de test Java dans le cadre d'une cible de build java_test_host, vous devrez utiliser ce qui suit pour injecter cette option :

cts-tradefed run cts --module-arg <module-name>:set-option:<option-name>:<option-value>

set-option dans ce contexte est l'option du coureur HostTest du harnais de test qui encapsule vos classes Java pour les exécuter.

si la cible de votre fichier jar pour les options contient plusieurs classes de test, par défaut, elles doivent toutes avoir l'@option spécifiée ou utiliser la syntaxe suivante pour cibler une seule classe :

cts-tradefed run cts --module-arg <module-name>:set-option:<class-name>:<option-name>:<option-value>

Passer les filtres à la suite

Pour filtrer certains tests d'une suite, nous utilisons --include-filter et --exclude-filter pour forcer respectivement l'inclusion ou l'exclusion d'un test ou d'un module particulier. L'exclusion est prioritaire.

Ils utilisent ce format : [abi] <module-name> [test name]

Exemples:

--include-filter CtsGestureTestCases

--include-filter armeabi-v7a CtsGestureTestCases

--include-filter armeabi-v7a CtsGestureTestCases android.gesture.cts.GestureTest#testGetStrokes
,

Tout d’abord, assurez-vous de bien comprendre la gestion des options dans Tradefed.

La configuration de la suite décrit les deux couches qui existent dans la structure de la suite :

  • La suite du haut niveau
  • Les modules

Dans un contexte Tradefed hors suite, il n’est pas nécessaire d’y penser ; chaque option va à l’invocation complète. Dans un contexte de suite, les modules restent isolés de la suite ; donc toutes les options ne sont pas disponibles à leur niveau.

Passer les options à la suite de niveau supérieur

La suite de niveau supérieur se comporte comme une configuration Tradefed standard : la configuration complète, y compris le coureur de suite, reçoit toutes les options comme une configuration Tradefed hors suite.

Passer les options aux modules

Les modules par défaut ne reçoivent aucune des options passées à la commande. Ils doivent être explicitement ciblés pour recevoir les options via l'option module-arg . Cette isolation des options des modules facilite le débogage.

Exemple:

cts-tradefed run cts --module-arg <module-name>:<option-name>:<option-value>

cts-tradefed run cts --module-arg CtsGestureTestCases:collect-tests-only:true

La syntaxe garantit que le module ciblé recevra l'option donnée.

Il existe des moyens supplémentaires pour transmettre des options aux modules tels que test-arg , qui vous permet de transmettre des options au programme d'exécution de test de chaque module en fonction du type ou de la classe du programme d'exécution.

Exemple:

cts-tradefed run cts --test-arg <test-class>:<option-name>:<option-value>

cts-tradefed run cts --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

La syntaxe ne cible pas un module particulier mais plutôt tous les lanceurs de tests de la classe donnée. test-arg ne considère que les implémentations de IRemoteTest comme récepteur potentiel des options.

Transmettre les options à une classe de test Java dans un java_test_host

Si vous ajoutez une @Option à votre classe de test Java dans le cadre d'une cible de build java_test_host, vous devrez utiliser ce qui suit pour injecter cette option :

cts-tradefed run cts --module-arg <module-name>:set-option:<option-name>:<option-value>

set-option dans ce contexte est l'option du coureur HostTest du harnais de test qui encapsule vos classes Java pour les exécuter.

si la cible de votre fichier jar pour les options contient plusieurs classes de test, par défaut, elles doivent toutes avoir l'@option spécifiée ou utiliser la syntaxe suivante pour cibler une seule classe :

cts-tradefed run cts --module-arg <module-name>:set-option:<class-name>:<option-name>:<option-value>

Passer les filtres à la suite

Pour filtrer certains tests d'une suite, nous utilisons --include-filter et --exclude-filter pour forcer respectivement l'inclusion ou l'exclusion d'un test ou d'un module particulier. L'exclusion est prioritaire.

Ils utilisent ce format : [abi] <module-name> [test name]

Exemples:

--include-filter CtsGestureTestCases

--include-filter armeabi-v7a CtsGestureTestCases

--include-filter armeabi-v7a CtsGestureTestCases android.gesture.cts.GestureTest#testGetStrokes