Una suite in Tradefed si riferisce a una configurazione in cui diversi test vengono eseguiti da un test runner comune che guida l'esecuzione complessiva.
In Tradefed, le suite vengono guidate attraverso la classe ITestSuite , che consente di aggiungere e rimuovere test indipendentemente da come vengono eseguiti.
Definizioni
- Suite: insieme di moduli di test configurati per essere eseguiti con una configurazione di livello superiore simile per riportare i risultati con un'unica invocazione.
- Configurazione di livello superiore: configurazione applicata ai dispositivi prima di eseguire qualsiasi modulo di test.
- Configurazione principale: la configurazione Tradefed XML a livello di suite che descrive quali moduli devono essere eseguiti e quale configurazione di livello superiore deve essere utilizzata.
- Configurazione a livello di modulo: configurazione applicata ai dispositivi subito prima di eseguire il modulo. Queste sono note anche come configurazioni specifiche del modulo .
- Configurazione del modulo: fa riferimento alla configurazione XML Tradefed
AndroidTest.xmlche descrive i moduli e quale configurazione a livello di modulo deve essere eseguita. - Modulo: unità di test composta da una fase di configurazione ( configurazione a livello di modulo ), una fase di esecuzione del test e una fase di smontaggio.
- Nuovo tentativo intra-modulo: nuovo tentativo automatico eseguito dal cablaggio all'interno del modulo.
- Nuovo tentativo della suite: ripetizione completa dei test precedentemente falliti della suite.
Struttura ITestSuite
ITestSuite in Tradefed si riferisce alla classe base comune che guida l'esecuzione di una suite. È condiviso da tutte le principali suite di test, in particolare Android Compatibility Test Suite (CTS) e Android Vendor Test Suite (VTS) , e garantisce un'esperienza di esecuzione coerente in tutte le suite.
A volte ci riferiamo a ITestSuite come suite runner .
Il corridore della suite segue questi passaggi durante l'esecuzione:
- Caricare la configurazione del modulo e determinare quale set deve essere eseguito.
Esegui ciascun modulo:
- Eseguire la configurazione a livello di modulo.
- Esegui test del modulo.
- Esegui lo smontaggio a livello di modulo.
Riporta i risultati.
Configurazione di primo livello
Dal punto di vista di Tradefed, ITestSuite è solo un altro test. È complesso ma è pur sempre solo un test come qualsiasi altro IRemoteTest . Pertanto, quando si specifica il suite runner in una configurazione Tradefed, Tradefed segue il solito schema della configurazione: esecuzione build_provider , target_preparer , test (la nostra suite in questo caso) e target_cleaner .
Questa sequenza nella configurazione Tradefed contenente ITestSuite è la configurazione di livello superiore.
Esempio:
<configuration description="Common config for Compatibility suites">
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<!-- Setup applied before the suite: so everything running in the suite will
have this setup beforehand -->
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put global package_verifier_enable 0" />
<option name="teardown-command" value="settings put global package_verifier_enable 1"/>
</target_preparer>
<!-- Our ITestSuite implementation -->
<test class="com.android.compatibility.common.tradefed.testtype.suite.CompatibilityTestSuite" />
<result_reporter class="com.android.compatibility.common.tradefed.result.ConsoleReporter" />
</configuration>
Metadati del modulo
Chiamiamo metadati del modulo informazioni aggiuntive specificate nel modulo di test AndroidTest.xml . Questi metadati consentono di specificare informazioni aggiuntive sul modulo e i moduli possono essere filtrati utilizzando i metadati.
Metadati di esempio:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Esempio di filtro sui metadati:
--module-metadata-include-filter component=framework
Quanto sopra eseguirebbe tutti i moduli con un framework come metadati dei componenti .
Esempio AndroidTest.xml completo:
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<!-- Metadata -->
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<!-- End: metadata -->
<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>
Modulo parametrizzato
Un tipo di metadati speciale è parameter .
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Questi metadati specificano che il modulo deve essere eseguito in una modalità diversa, ad esempio come app istantanea, anziché in modalità app standard.
Tutte le modalità o i parametri possibili sono descritti da ModuleParameters e hanno un gestore associato in ModuleParametersHelper che consente di modificare la configurazione del modulo per l'esecuzione in una modalità particolare.
Ad esempio, la modalità app istantanea impone l'installazione dell'APK come modalità istantanea.
Affinché la parametrizzazione avvenga è necessario abilitarla da riga di comando con:
--enable-parameterized-modules
È anche possibile eseguire una singola modalità con:
--enable-parameterized-modules --module-parameter <Mode>
--enable-parameterized-modules --module-parameter INSTANT_APP
Quando viene eseguita una versione con parametri di un modulo, segnala i risultati con un nome di modulo con parametri, ad esempio CtsGestureTestCases[instant] rispetto a base CtsGestureTestCases .