Konfiguracje Tradefed są zgodne ze strukturą XML, która opisuje test do wykonania oraz czynności przygotowawcze/konfiguracyjne.
Teoretycznie wszystko można zdefiniować w pliku XML dla pojedynczego polecenia. W praktyce jednak łatwiej jest mieć podstawowe pliki XML szablonu i dostosowywać je za pomocą dodatkowych parametrów wiersza poleceń.
Struktura
<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>
Cały plik XML Tradefed jest rozdzielany tagami <configuration>
. Tradefed
objects
są zdefiniowane w osobnych tagach, np. build_provider
, target_preparer
, test
itp. Ich indywidualne przeznaczenie jest opisane bardziej szczegółowo w sekcji Architektura.
Każdy obiekt ma powiązaną klasę Java z obiektem zdefiniowanym w class=
, który jest rozwiązywany w czasie wykonywania. Oznacza to, że jeśli plik JAR zawierający klasę znajduje się w czasie wykonywania na ścieżce klas Java w Tradefed, zostanie znaleziony i rozwiązany.
Zamówienia obiektów Tradefed
Kolejność tagów nie ma znaczenia. Na przykład nie ma znaczenia, czy po elemencie target_preparer
podano element build_provider
. Przepływ wywoływania testowego jest egzekwowany przez samą uprzęże, więc zawsze będzie je wywoływać we właściwej kolejności.
Kolejność obiektów z tym samym tagiem ma znaczenie. Na przykład 2 zdefiniowane obiekty target_preparer
będą wywoływane w kolejności ich definicji w pliku XML. Warto to wiedzieć, ponieważ może to zmienić końcowy stan konfiguracji urządzenia. Na przykład flashowanie, a następnie instalowanie pliku APK nie jest tym samym co instalowanie pliku APK i flashowanie, ponieważ flashowanie powoduje wyczyszczenie urządzenia.