Estrutura do AndroidTest.xml

A estrutura geral da configuração do módulo segue um padrão semelhante à configuração XML do Tradefed normal, mas com algumas restrições devido ao fato de serem executados como parte de um pacote.

Lista de tags permitidas

AndroidTest.xml ou, de forma mais ampla, 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 a execução do teste.

OBSERVAÇÃO: consulte Configuração de XML do Tradefed se você precisar relembrar as diferentes tags.

Objetos como build_provider ou result_reporter vão gerar uma ConfigurationException se forem executados de dentro de uma configuração de módulo. Isso evita a expectativa de que esses objetos realmente executem 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 de 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> em configurações de módulo não é recomendado. Não há garantia de que eles funcionem 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 querê-los recuperados 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 quanto a informações de build ou downloads?

A definição das tags permitidas pode dar a impressão incorreta de que um módulo não vai receber informações de build. Isso não é verdade.

As informações do build são fornecidas pela configuração no nível do pacote e compartilhadas por todos os módulos do pacote. Isso permite uma única configuração de nível superior para o pacote, a fim de executar todos os módulos que fazem parte dele.

Por exemplo, em vez de cada módulo do conjunto de teste de compatibilidade (CTS) consultar individualmente as informações do dispositivo, tipos etc., a configuração no nível do conjunto do CTS (cts.xml) faz isso uma vez, e cada módulo vai receber essas informações se elas forem solicitadas.

Para que os objetos em um módulo recebam as informações do build, eles precisam fazer o mesmo que na configuração normal do Tradefed: implementar a interface IBuildReceiver para receber o IBuildInfo. Consulte Como fazer testes com o 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 única.

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 CTS está disponível em CtsConfigLoadingTest. Esse teste falha na pré-envio se um componente inexistente for adicionado a um módulo CTS.

É possível filtrar uma execução de conjunto 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. Especifica a que modo do Android o módulo de teste se aplica. Nesse caso, os modos são limitados a modos de alto nível do Android, como instant apps, secondary users ou different abis.

Durante a execução do conjunto, se o modo for aplicado 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 com suporte do 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 desempenho, metrics_collector e metric_post_processor no nível do módulo são permitidos, porque são essenciais para testes de desempenho. 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 diferente de FilePullerLogCollector ou qualquer metric_post_processor, o teste vai falhar na pré-envio.

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>