Suite no Tradefed refere-se à configuração em que vários testes são executados em um executor de testes comum que orienta a execução geral.
No Tradefed, os conjuntos são conduzidos por meio da classe ITestSuite , que permite que os testes sejam adicionados e removidos independentemente de como são executados.
Definições
- Suite: Conjunto de módulos de teste configurados para serem executados em uma configuração de nível superior semelhante para relatar seus resultados em uma única chamada.
- Configuração de nível superior: Configuração aplicada ao(s) dispositivo(s) antes de executar qualquer um dos módulos de teste.
- Configuração principal: A configuração XML Tradefed de nível de suíte que descreve quais módulos devem ser executados e qual configuração de nível superior deve ser usada.
- Configuração em nível de módulo: Configuração aplicada ao(s) dispositivo(s) logo antes de executar o módulo. Elas também são conhecidas como configurações específicas do módulo .
- Configuração do módulo: Refere-se à configuração do
AndroidTest.xmlTradefed XML que descreve os módulos e qual configuração em nível de módulo deve ser feita. Módulo: Unidade de teste composta por uma etapa de configuração ( configuração em nível de módulo ), uma etapa de execução de teste e uma etapa de desmontagem.
Repetição intra-módulo: Repetição automática feita pelo chicote dentro do módulo.
Nova tentativa do conjunto: reexecução completa dos testes com falha anteriormente do conjunto.
Estrutura ITestSuite
ITestSuite no Tradefed refere-se à classe base comum que conduz a execução de uma suíte. Ele é compartilhado por todos os principais conjuntos de testes, especificamente o Android Compatibility Test Suite (CTS) e o Android Vendor Test Suite (VTS) e garante uma experiência de execução consistente em todos os conjuntos.
Às vezes, nos referimos ao ITestSuite como o executor de suítes .
O executor da suíte segue estas etapas ao executar:
- Carregue a configuração do módulo e determine qual conjunto deve ser executado.
- Execute cada módulo: a. Execute a configuração em nível de módulo b. Executar testes de módulo c. Execute a desmontagem no nível do módulo
- Informe os resultados
Configuração de nível superior
Do ponto de vista do Tradefed, o ITestSuite é apenas mais um teste. É complexo, mas ainda é apenas um teste como qualquer outro IRemoteTest . Portanto, ao especificar o executor do conjunto em uma configuração do Tradefed, o Tradefed seguirá o padrão usual da configuração: executando build_provider , target_preparer , test (nosso conjunto neste caso) e target_cleaner .
Essa sequência na configuração Tradefed contendo o ITestSuite é a configuração de nível superior.
Exemplo:
<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>
Metadados do módulo
Chamamos as informações extras de metadados do módulo especificadas no módulo de teste AndroidTest.xml . Eles permitem que você especifique informações adicionais sobre o módulo, e os módulos podem ser filtrados usando os metadados.
Metadados de exemplo:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Exemplo de filtro em metadados:
--module-metadata-include-filter component=framework
O acima executaria todos os módulos com uma estrutura como metadados de componentes .
Exemplo completo AndroidTest.xml :
<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>
Módulo parametrizado
Um tipo de metadados especial é o parameter .
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Esses metadados especificam que o módulo precisará ser executado em um modo diferente , por exemplo, como um aplicativo instantâneo, em vez de um modo de aplicativo padrão.
Todos os modos ou parâmetros possíveis são descritos por ModuleParameters e possuem um manipulador associado em ModuleParametersHelper que permite alterar a configuração do módulo para executar no modo específico.
Por exemplo, o modo de aplicativo instantâneo forçará a instalação do APK como modo instantâneo.
Para que a parametrização ocorra, a linha de comando precisa habilitá-la via:
--enable-parameterized-modules
Também é possível executar um único modo determinado via:
--enable-parameterized-modules --module-parameter <Mode>
--enable-parameterized-modules --module-parameter INSTANT_APP
Quando uma versão parametrizada de um módulo é executada, ela relatará seus resultados sob um nome de módulo parametrizado, por exemplo CtsGestureTestCases[instant] vs. base CtsGestureTestCases.