A estrutura geral da configuração do módulo segue um padrão semelhante à configuração XML normal do Tradefed, mas com algumas restrições devido ao fato de serem executadas como parte de um conjunto.
Lista de tags permitidas
AndroidTest.xml ou, de maneira mais geral, a configuração do módulo pode conter apenas as seguintes tags XML: target_preparer, multi_target_preparer, test e metrics_collector.
Embora essa lista pareça restritiva, ela permite definir com precisão as necessidades de configuração do módulo de teste e o teste a ser executado.
OBSERVAÇÃO: consulte Configuração XML do Tradefed se precisar relembrar as diferentes tags.
Objetos como build_provider ou result_reporter vão gerar um
ConfigurationException se forem executados de dentro de uma configuração
de módulo. Isso evita a expectativa de que esses objetos realmente realizem alguma tarefa em um módulo.
Exemplo de configuração de módulo
<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>
Essa configuração descreve um teste que exige a instalação do CtsGestureTestCases.apk e executa uma instrumentação no pacote android.gesture.cts.
Tags de inclusão <include> e <template-include>
O uso de <include> e <template-include> nas configurações de módulo não é recomendado. Não há garantia de que eles vão funcionar como esperado.
Caso especial para a tag metrics_collector
O metrics_collector é permitido, mas limitado à classe
FilePullerLogCollector
para especificar um determinado arquivo ou diretório a ser extraído e registrado para
o módulo. Isso é útil se você estiver deixando registros em um local específico e quiser recuperá-los automaticamente.
Exemplo de configuração:
<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>
E as informações de build ou os downloads?
A definição das tags permitidas pode dar a impressão incorreta de que um módulo não vai receber nenhuma informação de build. Isso não é verdade.
As informações de build são fornecidas pela configuração no nível do pacote e são compartilhadas por todos os módulos do pacote. Isso permite uma única configuração de nível superior para o pacote e executa todos os módulos dele.
Por exemplo, em vez de cada módulo do Compatibility Test Suite (CTS) consultar individualmente as informações, os tipos etc. do dispositivo, a configuração no nível do conjunto do CTS (cts.xml) faz isso uma vez, e cada módulo recebe essas informações se solicitar.
Para que os objetos em um módulo recebam as informações de build, eles precisam
fazer o mesmo que em uma configuração regular do Tradefed: implementar a
interface IBuildReceiver para receber o IBuildInfo. Consulte
testes com dispositivo
para mais detalhes.
Campos de metadados
Um grande número de módulos de teste inclui algumas especificações metadata, cada uma com uma meta exclusiva.
Exemplo:
<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" />
Componente
Os metadados component descrevem o componente geral do Android que o módulo
pretende testar. Ele não tem impacto direto na execução do teste, sendo usado principalmente para fins organizacionais.
A lista atualizada de componentes permitidos para o CTS está disponível em CtsConfigLoadingTest. Esse teste falha na pré-submissão se um componente inexistente for adicionado a um módulo do CTS.
É possível filtrar uma execução de pacote com base nos componentes usando
module-metadata-include-filter e module-metadata-exclude-filter.
Exemplo:
--module-metadata-include-filter component framework
Este exemplo executa apenas o módulo de teste anotado com o componente framework.
Parâmetro
Os metadados parameter são informativos e afetam a execução do teste. Ele especifica a qual modo do Android o módulo de teste se aplica.
Nesse caso, os modos são limitados a modos Android de alto nível, como
instant apps, secondary users ou different abis.
Durante a execução do conjunto, se o modo se aplicar ao teste, várias variações do módulo de teste serão criadas com base no modo. Cada variação executa testes semelhantes, mas em modos diferentes.
instant_app: crie uma variação dos testes que instalam APKs como apps instantâneos.multi_abi: crie uma variação dos testes para cada ABI compatível com o dispositivo.secondary_user: crie uma variação dos testes que instalam APKs e executam testes como um usuário secundário.
Coleta de métricas e pós-processamento para módulos de teste de desempenho
Para módulos de teste de performance, metrics_collector e metric_post_processor no nível do módulo são permitidos porque são essenciais para testes de performance.
Os coletores de métricas e pós-processadores no nível do módulo podem ser específicos do módulo.
Não é recomendável especificar pós-processadores no nível superior e no nível do módulo.
Uma configuração de módulo de teste de desempenho precisa incluir os metadados test-type com o valor performance, como: xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />. Sem isso, se uma configuração de teste incluir metric_collector que não seja FilePullerLogCollector ou qualquer metric_post_processor, o teste vai falhar na pré-submissão.
Exemplo de configuração do módulo de teste de desempenho:
<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>