Auf dieser Seite wird beschrieben, wie Sie einen neuen Test-Runner in Tradefed schreiben.
Hintergrund
Wenn Sie wissen möchten, wo sich Test-Runner in der Tradefed-Architektur befinden, lesen Sie den Abschnitt Struktur eines Test-Runners.
Dies ist keine Voraussetzung für das Schreiben eines neuen Test Runners. Test Runners können unabhängig voneinander geschrieben werden.
Mindestanforderungen: Implementieren Sie die Benutzeroberfläche.
Um als Tradefed-Test-Runner infrage zu kommen, müssen Sie mindestens die IRemoteTest-Schnittstelle und insbesondere die run(TestInformation testInfo, ITestInvocationListener listener)-Methode implementieren.
Diese Methode wird vom Harness bei Verwendung des Test-Runners aufgerufen, ähnlich wie bei einem Java-Runnable.
Jeder Teil dieser Methode wird als Teil der Ausführung des Test-Runners betrachtet.
Ergebnisse aus dem Test-Runner melden
Die Methode run in der Basisschnittstelle bietet Zugriff auf ein Listener-Objekt vom Typ ITestInvocationListener. Dieses Objekt ist der Schlüssel zur Berichterstellung strukturierter Ergebnisse vom Test-Runner an das Harness.
Durch die Meldung strukturierter Ergebnisse hat ein Test-Runner die folgenden Eigenschaften:
- Geben Sie eine vollständige Liste aller durchgeführten Tests, ihre Dauer und den Status an, ob sie bestanden, fehlgeschlagen oder in einem anderen Status sind.
- Geben Sie gegebenenfalls Messwerte zu den Tests an, z. B. Messwerte zur Installationszeit.
- Sie passt in die meisten Infrastrukturtools, z. B. für die Anzeige von Ergebnissen und Messwerten.
- Normalerweise einfacher zu beheben, da es eine detailliertere Ausführungsspur gibt.
Das Erfassen strukturierter Ergebnisse ist jedoch optional. Ein Testausführer kann den Status des gesamten Durchlaufs einfach als „BESTANDEN“ oder „NICHT BESTANDEN“ bewerten, ohne Details zur tatsächlichen Ausführung anzugeben.
Die folgenden Ereignisse können beim Listener aufgerufen werden, um den Harness über den aktuellen Fortschritt der Ausführungen zu informieren:
- testRunStarted: Benachrichtigt über den Beginn einer Gruppe von Testfällen, die miteinander zusammenhängen.
- testStarted: Benachrichtigen, wenn ein Testlauf gestartet wird.
- testFailed/testIgnored: Benachrichtigung über den Statuswechsel des laufenden Testfalls. Ein Testfall ohne Statusänderung gilt als bestanden.
- testEnded: Benachrichtigt über das Ende des Testfalls.
- testRunFailed: Gibt an, dass der Gesamtstatus der Gruppe der Testlaufausführungen ein Fehler ist. Ein Testlauf kann erfolgreich oder fehlgeschlagen sein, unabhängig von den Ergebnissen der Testfälle, je nachdem, was bei der Ausführung erwartet wurde. Beispiel: Ein Binärprogramm, in dem mehrere Testfälle ausgeführt werden, könnte alle Testfälle als Erfolgreich melden, aber einen Fehler-Exit-Code ausgeben (aus beliebigen Gründen, z. B. durch geleakte Dateien).
- testRunEnded: Benachrichtigt über das Ende der Gruppe von Testfällen.
Die Aufrechterhaltung und Gewährleistung der richtigen Reihenfolge der Callbacks liegt in der Verantwortung des Test-Runner-Implementierers. Er muss beispielsweise dafür sorgen, dass testRunEnded im Fall eines Ausnahmefehlers mit einer finally-Klausel aufgerufen wird.
Testlauf-Callbacks (testStarted, testEnded usw.) sind optional. Ein Testlauf kann ohne Testfälle erfolgen.
Sie werden feststellen, dass diese Ereignisstruktur von der typischen JUnit-Struktur inspiriert ist. Das soll Entwicklern den Einstieg erleichtern.
Protokolle aus dem Test-Runner melden
Wenn Sie Ihre eigene Tradefed-Testklasse oder ‑Ausführung schreiben, implementieren Sie IRemoteTest und erhalten eine ITestInvocationListener über die Methode run(). Dieser Listener kann so zum Loggen von Dateien verwendet werden:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Mit einem Gerät testen
Mit der minimalen Schnittstelle oben können sehr einfache Tests ausgeführt werden, die isoliert sind und keine bestimmten Ressourcen erfordern, z. B. Java-Unit-Tests.
Testautoren, die mit dem nächsten Schritt des Gerätetests fortfahren möchten, benötigen die folgenden Oberflächen:
- Mit IDeviceTest können Sie das
ITestDevice-Objekt abrufen, das das zu testende Gerät darstellt, und die API für die Interaktion damit bereitstellen. - Mit IBuildReceiver kann der Test das
IBuildInfo-Objekt abrufen, das im Build-Anbieterschritt erstellt wurde und alle Informationen und Artefakte zur Testeinrichtung enthält.
Testausführer sind in der Regel an diesen Schnittstellen interessiert, um Artefakte im Zusammenhang mit der Ausführung abzurufen, z. B. zusätzliche Dateien, und das Testgerät abzurufen, auf das während der Ausführung ausgerichtet werden soll.
Mit mehreren Geräten testen
Tradefed unterstützt die Ausführung von Tests auf mehreren Geräten gleichzeitig. Dies ist nützlich, wenn Sie Komponenten testen, die eine externe Interaktion erfordern, z. B. das Koppeln eines Smartphones mit einer Smartwatch.
Wenn Sie einen Test-Runner schreiben möchten, der mehrere Geräte verwenden kann, müssen Sie die IMultiDeviceTest implementieren. Dadurch wird eine Zuordnung von ITestDevice zu IBuildInfo empfangen, die die vollständige Liste der Gerätedarstellungen und die zugehörigen Build-Informationen enthält.
Der Setter aus der Schnittstelle wird immer vor der run-Methode aufgerufen. Daher ist davon auszugehen, dass die Struktur beim Aufrufen von run verfügbar ist.
Tests, die die Konfiguration berücksichtigen
Für einige Test-Runner-Implementierungen sind möglicherweise Informationen zur Gesamteinrichtung erforderlich, damit sie ordnungsgemäß funktionieren, z. B. einige Metadaten zum Aufruf oder die zuvor ausgeführte target_preparer.
Dazu kann ein Test-Runner auf das IConfiguration-Objekt zugreifen, zu dem er gehört und in dem er ausgeführt wird. Weitere Informationen finden Sie in der Beschreibung des Konfigurationsobjekts.
Für die Implementierung des Testlaufs müssen Sie die IConfigurationReceiver implementieren, um das IConfiguration-Objekt zu empfangen.
Flexibler Test-Runner
Testläufer können eine flexible Möglichkeit zum Ausführen von Tests bieten, wenn sie eine detaillierte Kontrolle darüber haben. So kann ein JUnit-Testläufer beispielsweise jeden Unit-Test einzeln ausführen.
Dadurch können der größere Dienst und die Infrastruktur diese feine Steuerung nutzen und die Nutzer können den Test-Runner teilweise über Filtern ausführen.
Die Filterunterstützung wird in der ITestFilterReceiver-Oberfläche beschrieben, mit der Sie Gruppen von include- und exclude-Filtern für die Tests erhalten können, die ausgeführt werden sollen oder nicht.
Ein Test wird nur dann ausgeführt, wenn er mit mindestens einem der Einschlussfilter übereinstimmt UND mit keinem der Ausschlussfilter. Wenn keine Einschlussfilter angegeben sind, sollten alle Tests ausgeführt werden, sofern sie keinem der Ausschlussfilter entsprechen.