Le configurazioni di TradeFed seguono una struttura XML per descrivere il test da eseguire e i passaggi di preparazione/configurazione da svolgere.
In teoria, tutto può essere definito nel file XML per un singolo comando. Tuttavia, in pratica, è più pratico avere file XML di modelli di base e personalizzarli con parametri aggiuntivi della riga di comando.
Struttura
<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>
Il file XML Tradefed complessivo è delimitato da tag <configuration>. I Tradefed
objects sono definiti nei propri tag, ad esempio build_provider,
target_preparer, test e così via. I singoli scopi sono descritti più
in dettaglio nella sezione Architettura.
A ogni oggetto è associata la classe Java associata all'oggetto definito in class= che viene risolta in fase di runtime, purché il file JAR contenente la classe sia nel classpath Java Tradefed durante l'esecuzione, verrà trovato e risolto.
Ordini di oggetti Tradefed
L'ordine dei diversi tag non è importante. Ad esempio, non fa alcuna differenza se build_provider viene specificato dopo target_preparer. Il flusso
dell'invocazione del test viene applicato dall'harness stesso, quindi li chiamerà sempre
nell'ordine corretto.
L'ordine degli oggetti con lo stesso tag è importante. Ad esempio, due oggetti target_preparer definiti verranno chiamati nell'ordine di definizione nel file XML. È importante comprenderlo perché può cambiare lo stato finale
della configurazione del dispositivo. Ad esempio, fare il flashing e poi installare un APK non è lo stesso che installare un APK e fare il flashing, poiché il flashing cancellerebbe i dati del dispositivo.