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
A configuração do módulo AndroidTest.xml ou mais amplamente 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 Tradefed XML se precisar de uma atualização sobre as diferentes tags.
Objetos como build_provider ou result_reporter uma ConfigurationException se tentarem ser executados de dentro de uma configuração de módulo. Isso visa evitar a expectativa de que esses objetos realmente executem alguma tarefa de 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 que o CtsGestureTestCases.apk seja instalado 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 obtido e registrado para o módulo. Isso é útil se você estiver deixando logs 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 quanto a 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 receberá nenhuma informação de compilação. Isso não é verdade .
As informações de compilação são fornecidas a partir da configuração em nível de suíte e serão compartilhadas por todos os módulos da suíte. 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 de Compatibility Test Suite (CTS) consultar individualmente as informações do dispositivo, tipos, etc., a configuração de nível de suite CTS ( cts.xml ) faz isso uma vez e cada módulo receberá essa informação se solicitar.
Para que os objetos em um módulo recebam as informações de compilação, eles precisam fazer o mesmo que na configuração normal 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 de metadata , cada uma 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 do 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 de framework .
Parâmetro
Os metadados do parameter são informativos e impactam 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 suportada pelo dispositivo. -
secondary_user: crie uma variação dos testes que instalam APKs e executam testes como usuário secundário.