Innanzitutto, assicurati di comprendere la gestione delle opzioni in Tradefed.
La configurazione della suite descrive i due livelli esistenti nella struttura della suite:
- La suite di altissimo livello
- I moduli
In un contesto non-suite Tradefed, non c’è bisogno di pensarci; ogni opzione vale per l'invocazione completa. In un contesto di suite, i moduli vengono mantenuti isolati dalla suite; quindi non tutte le opzioni sono disponibili al loro livello.
Passa le opzioni alla suite di livello superiore
La suite di livello superiore si comporta come la configurazione Tradefed standard: la configurazione completa, incluso il runner della suite, riceve tutte le opzioni come una configurazione Tradefed non suite.
Passa le opzioni ai moduli
Per impostazione predefinita, i moduli non ricevono nessuna delle opzioni passate al comando. Devono essere esplicitamente mirati per ricevere le opzioni tramite l'opzione module-arg
. Questo isolamento delle opzioni dei moduli semplifica il debug.
Esempio:
cts-tradefed run cts --module-arg <module-name>:<option-name>:<option-value>
cts-tradefed run cts --module-arg CtsGestureTestCases:collect-tests-only:true
La sintassi garantisce che il modulo di destinazione riceverà l'opzione specificata.
Esistono ulteriori modi per passare le opzioni ai moduli come test-arg
, che consente di passare le opzioni al test runner di ciascun modulo in base al tipo o alla classe del runner.
Esempio:
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 sintassi non si rivolge a un modulo particolare ma piuttosto a tutti i test runner di una determinata classe. test-arg
considera solo le implementazioni di IRemoteTest come potenziale destinatario delle opzioni.
Passa le opzioni a una classe di test Java in un java_test_host
Se stai aggiungendo una @Option
alla tua classe di test Java come parte di un target di build java_test_host, dovrai utilizzare quanto segue per inserire tale opzione:
cts-tradefed run cts --module-arg <module-name>:set-option:<option-name>:<option-value>
set-option in questo contesto è l'opzione del runner HostTest dal test cablaggio che avvolge le classi Java per eseguirle.
se la destinazione del file jar per le opzioni contiene più classi di test, per impostazione predefinita è previsto che tutte abbiano la @option specificata o utilizzino la seguente sintassi per indirizzare una singola classe:
cts-tradefed run cts --module-arg <module-name>:set-option:<class-name>:<option-name>:<option-value>
Passa i filtri alla suite
Per filtrare alcuni test da una suite, utilizziamo --include-filter
e --exclude-filter
rispettivamente per forzare l'inclusione o l'esclusione di un particolare test o modulo. L'esclusione ha la priorità.
Usano questo formato: [abi] <module-name> [test name]
Esempi:
--include-filter CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases android.gesture.cts.GestureTest#testGetStrokes
, Innanzitutto, assicurati di comprendere la gestione delle opzioni in Tradefed.
La configurazione della suite descrive i due livelli esistenti nella struttura della suite:
- La suite di altissimo livello
- I moduli
In un contesto non-suite Tradefed, non c’è bisogno di pensarci; ogni opzione vale per l'invocazione completa. In un contesto di suite, i moduli vengono mantenuti isolati dalla suite; quindi non tutte le opzioni sono disponibili al loro livello.
Passa le opzioni alla suite di livello superiore
La suite di livello superiore si comporta come la configurazione Tradefed standard: la configurazione completa, incluso il runner della suite, riceve tutte le opzioni come una configurazione Tradefed non suite.
Passa le opzioni ai moduli
Per impostazione predefinita, i moduli non ricevono nessuna delle opzioni passate al comando. Devono essere esplicitamente mirati per ricevere le opzioni tramite l'opzione module-arg
. Questo isolamento delle opzioni dei moduli semplifica il debug.
Esempio:
cts-tradefed run cts --module-arg <module-name>:<option-name>:<option-value>
cts-tradefed run cts --module-arg CtsGestureTestCases:collect-tests-only:true
La sintassi garantisce che il modulo di destinazione riceverà l'opzione specificata.
Esistono ulteriori modi per passare le opzioni ai moduli come test-arg
, che consente di passare le opzioni al test runner di ciascun modulo in base al tipo o alla classe del runner.
Esempio:
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 sintassi non si rivolge a un modulo particolare ma piuttosto a tutti i test runner di una determinata classe. test-arg
considera solo le implementazioni di IRemoteTest come potenziale destinatario delle opzioni.
Passa le opzioni a una classe di test Java in un java_test_host
Se stai aggiungendo una @Option
alla tua classe di test Java come parte di un target di build java_test_host, dovrai utilizzare quanto segue per inserire tale opzione:
cts-tradefed run cts --module-arg <module-name>:set-option:<option-name>:<option-value>
set-option in questo contesto è l'opzione del runner HostTest dal test cablaggio che avvolge le classi Java per eseguirle.
se la destinazione del file jar per le opzioni contiene più classi di test, per impostazione predefinita è previsto che tutte abbiano la @option specificata o utilizzino la seguente sintassi per indirizzare una singola classe:
cts-tradefed run cts --module-arg <module-name>:set-option:<class-name>:<option-name>:<option-value>
Passa i filtri alla suite
Per filtrare alcuni test da una suite, utilizziamo --include-filter
e --exclude-filter
rispettivamente per forzare l'inclusione o l'esclusione di un particolare test o modulo. L'esclusione ha la priorità.
Usano questo formato: [abi] <module-name> [test name]
Esempi:
--include-filter CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases
--include-filter armeabi-v7a CtsGestureTestCases android.gesture.cts.GestureTest#testGetStrokes