A estrutura geral da configuração do módulo segue um padrão semelhante à configuração regular do Tradefed XML, mas com algumas restrições devido ao fato de serem executados como parte de um conjunto.
Lista de tags permitidas
AndroidTest.xml ou configuração de módulo mais ampla pode conter apenas as seguintes tags XML: target_preparer , multi_target_preparer , test 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.
NOTA: Consulte a configuração do Tradefed XML se precisar de uma atualização nas diferentes tags.
Objetos como build_provider ou result_reporter gerarão uma ConfigurationException se tentarem ser executados de dentro de uma configuração de módulo. Isso serve para evitar a expectativa de que esses objetos realmente executem alguma tarefa dentro de 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>
Esta configuração descreve um teste que requer a instalação CtsGestureTestCases.apk e executará uma instrumentação no pacote android.gesture.cts .
Caso especial para a tag metrics_collector
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 logs em um determinado local 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 compilação ou downloads?
A definição das tags permitidas pode dar a impressão incorreta de que um módulo não obterá nenhuma informação de compilação. Isso não é verdade .
As informações de compilação são fornecidas a partir da configuração no nível do conjunto e serão compartilhadas por todos os módulos do conjunto. Isso permite uma única configuração de nível superior para a suíte para executar todos os módulos que fazem parte da suíte.
Por exemplo, em vez de cada módulo do Conjunto de Testes de Compatibilidade (CTS) consultar individualmente as informações, tipos, etc. do dispositivo, a configuração do nível do conjunto do CTS ( cts.xml ) faz isso uma vez e cada módulo receberá essas informações se solicitado.
Para que os objetos em um módulo recebam as informações de construção, eles precisam fazer o mesmo que na configuração regular do Tradefed: implementar a interface IBuildReceiver para receber o IBuildInfo . Consulte o teste com o dispositivo para obter mais detalhes.
Campos de metadados
Um grande número de módulos de teste inclui algumas especificações metadata , cada uma com um objetivo exclusivo.
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. Não tem impacto direto na execução do teste; é usado principalmente para fins organizacionais.
A lista atualizada de componentes permitidos para CTS está disponível em CtsConfigLoadingTest . Este teste falha no pré-envio se um componente inexistente for adicionado a um módulo CTS.
Você pode 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. Ele especifica a qual modo 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.