Estrutura do AndroidTest.xml

A estrutura geral da configuração do módulo segue um padrão semelhante à configuração XML 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 uma configuração de módulo mais ampla pode conter apenas o 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 XML do Tradefed se precisar de uma revisão nas 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 dessas objetos que de fato realizam alguma tarefa em um módulo.

Exemplo de configuração do 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 que CtsGestureTestCases.apk para será instalado e vai executar uma instrumentação no 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 da tag metrics_collector

O metrics_collector é permitido, mas limitado aos FilePullerLogCollector para especificar um determinado arquivo ou diretório a ser puxado e registrado para no 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 às 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 dele.

Por exemplo, em vez de cada Conjunto de teste de compatibilidade (CTS) consultando individualmente as informações, os tipos etc. do dispositivo, o CTS a configuração no nível do pacote (cts.xml) faz isso uma vez, e cada módulo recebe esse informações caso elas solicitem.

Para que os objetos em um módulo recebam as informações do build, eles precisam para fazer o mesmo da configuração normal do Tradefed: implemente o IBuildReceiver para receber o IBuildInfo. Consulte teste com dispositivo para mais detalhes.

Campos de metadados

Um grande número de módulos de teste inclui algumas especificações metadata, com um objetivo único.

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. Este teste vai falhar no pré-envio 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 o teste execução. 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 pacote, se o modo se aplicar ao teste, várias variações do módulo de teste sã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: cria uma variação dos testes que instalam APKs e executar 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, os módulos metrics_collector e metric_post_processor são permitidas 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 é recomendado especificar pós-processadores em 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>