As configurações do Tradefed seguem uma estrutura XML para descrever o teste a ser executado e as etapas de preparação/configuração a serem realizadas.
Em teoria, tudo pode ser definido no XML para um único comando. Na prática, é mais prático ter arquivos XML de modelo base e personalizá-los com parâmetros extras de linha de comando.
Estrutura
<configuration description="<description of the configuration>">
<!-- A build provider that takes local device information -->
<build_provider class="com.android.tradefed.build.BootstrapBuildProvider" />
<!-- Some target preparation, disabled by default -->
<target_preparer class="com.android.tradefed.targetprep.PreloadedClassesPreparer">
<option name="disable" value="true" />
</target_preparer>
<!-- One test running some unit tests -->
<test class="com.android.tradefed.testtype.HostTest">
<option name="class" value="com.android.tradefed.build.BuildInfoTest" />
</test>
<!-- [OPTIONAL] -->
<logger class="com.android.tradefed.log.FileLogger">
<option name="log-level" value="VERBOSE" />
<option name="log-level-display" value="VERBOSE" />
</logger>
<!-- [OPTIONAL] -->
<log_saver class="com.android.tradefed.result.FileSystemLogSaver" />
<!-- As many reporters as we want -->
<result_reporter class="com.android.tradefed.result.ConsoleResultReporter" />
<result_reporter class="com.android.tradefed.result.suite.SuiteResultReporter" />
<result_reporter class="com.android.tradefed.result.MetricsXMLResultReporter"/>
</configuration>
O XML geral do Tradefed é delimitado por tags <configuration>
. Tradefed
objects
são definidos nas próprias tags, por exemplo: build_provider
, target_preparer
, test
etc. As finalidades individuais são descritas em mais detalhes na seção Arquitetura.
Cada objeto tem a classe Java associada ao objeto definido em class=
que é resolvido no tempo de execução. Portanto, contanto que o arquivo JAR que contém a classe esteja
no caminho de classe Java do Tradefed durante a execução, ele será encontrado e resolvido.
Pedidos de objetos do Tradefed
A ordem das tags não importa. Por exemplo, não faz
diferença se build_provider
for especificado após target_preparer
. O fluxo da
invocação de teste é aplicado pelo próprio harness. Por isso, ele sempre será chamado
na ordem correta.
A ordem dos objetos com a mesma tag importa. Por exemplo, dois
objetos target_preparer
definidos serão chamados na ordem de definição no
XML. É importante entender isso, porque pode mudar o estado final da
configuração do dispositivo. Por exemplo, instalar um apk e depois fazer o flash dele não é o
mesmo que instalar um apk e fazer o flash dele, já que o flash exclui todos os dados do dispositivo.