O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Estrutura de 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 tentarem ser executados 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 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 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 na configuração no nível do pacote e serão 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 módulo do conjunto de teste de compatibilidade (CTS) consultar individualmente as informações do dispositivo, tipos etc., a configuração do 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 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. 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 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: cria 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 um metric_collector diferente de FilePullerLogCollector ou qualquer metric_post_processor, o teste falhará no 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>