Auf dieser Seite wird beschrieben, wie Sie einen neuen Test-Runner in Tradefed schreiben.
Hintergrund
Informationen zur Rolle von Testläufern in der Tradefed-Architektur finden Sie unter Struktur eines Testlaufs.
Dies ist keine Voraussetzung für das Schreiben eines neuen Test-Runners. Test-Runner können isoliert 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 bei Verwendung des Test-Runners vom Harness 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 run-Methode 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 Berichterstellung strukturierter Ergebnisse hat ein Test-Runner die folgenden Eigenschaften:
- Erstellen Sie einen Bericht über alle ausgeführten Tests, wie lange sie gedauert haben und ob sie einzeln bestanden wurden, nicht bestanden oder einen anderen Status aufweisen.
- Geben Sie gegebenenfalls Messwerte für die 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 auf dem Listener aufgerufen werden, um das Nutzsystem über den aktuellen Fortschritt der Ausführungen zu informieren:
- testRunStarted: Benachrichtigt über den Beginn einer Gruppe von Testfällen, die miteinander zusammenhängen.
- testStarted: Benachrichtigung zum Starten eines Testfalls.
- 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: Benachrichtigung, dass die Ausführung der Testfallgruppe fehlgeschlagen 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 Implementierung des Testlaufs ist dafür verantwortlich, die richtige Reihenfolge der Rückrufe beizubehalten und sicherzustellen, dass testRunEnded bei einer Ausnahme mit einer finally-Klausel aufgerufen wird.
Testlauf-Callbacks (testStarted, testEnded usw.) sind optional. Ein Testlauf kann ohne Testfälle erfolgen.
Diese Ereignisstruktur ist von der typischen JUnit-Struktur inspiriert. Damit möchten wir dafür sorgen, dass die Grundlagen so gut wie möglich bleiben, mit der Entwickler sich normalerweise auskennen.
Protokolle aus dem Test-Runner melden
Wenn Sie eine eigene Tradefed-Testklasse oder einen eigenen Runner schreiben, implementieren Sie IRemoteTest und erhalten über die Methode run() einen ITestInvocationListener. Mit diesem Listener können Sie Dateien so protokollieren:
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 der Gerätetests fortfahren möchten, benötigen die folgenden Schnittstellen:
- 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 gleichzeitige Durchführung von Tests auf mehreren Geräten. Das ist nützlich, wenn Komponenten getestet werden, für die eine externe Interaktion erforderlich ist, z. B. die Kopplung eines Smartphones mit einer Smartwatch.
Wenn Sie einen Test-Runner schreiben möchten, der mehrere Geräte verwenden kann, müssen Sie den IMultiDeviceTest implementieren. Dieser ermöglicht das Empfangen einer Zuordnung von ITestDevice zu IBuildInfo, die die vollständige Liste der Gerätedarstellungen und die zugehörigen Build-Informationen enthält.
Der Setter der Schnittstelle wird immer vor der Methode run aufgerufen. Daher kann davon ausgegangen werden, dass die Struktur verfügbar ist, wenn run aufgerufen wird.
Tests, die die Konfiguration berücksichtigen
Für einige Testlauf-Implementierungen sind möglicherweise Informationen zur Gesamtkonfiguration erforderlich, damit sie ordnungsgemäß funktionieren, z. B. Metadaten zur Aufrufung oder dazu, welche target_preparer zuvor ausgeführt wurde.
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 Testausführer
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.
So können die größere Testumgebung und die Infrastruktur diese detaillierte Kontrolle nutzen und Nutzer können den Test-Runner teilweise über Filter ausführen.
Die Filterunterstützung wird in der ITestFilterReceiver-Schnittstelle beschrieben. Damit können include- und exclude-Filtersätze für die Tests empfangen werden, 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.