Konfigurasi Tradefed mengikuti struktur XML untuk mendeskripsikan pengujian yang akan dijalankan dan langkah-langkah persiapan/penyiapan yang akan dilakukan.
Secara teori, semuanya dapat ditentukan dalam XML untuk satu perintah. Namun dalam praktiknya, akan lebih praktis untuk memiliki file XML template dasar dan menyesuaikannya dengan parameter command line tambahan.
Struktur
<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>
XML Tradefed secara keseluruhan dibatasi oleh tag <configuration>
. Tradefed
objects
ditentukan dalam tagnya sendiri, misalnya: build_provider
,
target_preparer
, test
, dll. Tujuan masing-masing dijelaskan secara
lebih mendetail di bagian Arsitektur.
Setiap objek memiliki class Java yang terkait dengan objek yang ditentukan dalam class=
yang di-resolve saat runtime; jadi selama file JAR yang berisi class berada
di classpath Java Tradefed saat berjalan, file tersebut akan ditemukan dan di-resolve.
Urutan objek Tradefed
Urutan tag yang berbeda tidak menjadi masalah. Misalnya, tidak ada
perbedaan jika build_provider
ditentukan setelah target_preparer
. Alur
pemanggilan pengujian diterapkan oleh harness itu sendiri, sehingga akan selalu memanggilnya
dalam urutan yang benar.
Urutan objek dengan tag yang sama memang penting. Misalnya, dua
objek target_preparer
yang ditentukan akan dipanggil dalam urutan definisinya di
XML. Penting untuk dipahami karena dapat mengubah status akhir
penyiapan perangkat. Misalnya, meng-flash lalu menginstal apk tidak akan
sama dengan menginstal apk dan meng-flash karena flashing akan menghapus total perangkat.