Le configurazioni di Tradefed seguono una struttura XML per descrivere il test da eseguire e i passaggi di preparazione/configurazione da eseguire.
In teoria, tutto può essere definito nell'XML per un singolo comando. In pratica, però, è più pratico avere file XML di modelli di base e personalizzarli con parametri della riga di comando aggiuntivi.
Strutturazione
<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>
L'XML di Tradefed complessivo è delimitato dai tag <configuration>. Tradefed
objects sono definiti nei propri tag, ad esempio: build_provider,
target_preparer, test e così via. I loro scopi individuali sono descritti in modo più
dettagliato nella sezione Architettura.
Ogni oggetto ha la classe Java associata all'oggetto definito in class= che viene risolto in fase di runtime. Pertanto, se il file JAR contenente la classe si trova nel classpath Java di Tradefed durante l'esecuzione, verrà trovato e risolto.
Ordini degli oggetti Tradefed
L'ordine dei diversi tag non è importante. Ad esempio, non fa differenza se build_provider viene specificato dopo target_preparer. Il flusso della chiamata di 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 nell'XML. È importante comprendere questo aspetto perché può modificare lo stato finale della configurazione del dispositivo. Ad esempio, flashare e poi installare un APK non è la stessa cosa di installare un APK e flashare , poiché il flashing cancellerebbe i dati del dispositivo.