Auf dieser Seite wird beschrieben, wie Sie einen neuen Test-Runner in Tradefed schreiben.
Hintergrund
Wenn Sie mehr über die Rolle von Test-Runnern in der Tradefed-Architektur erfahren möchten, lesen Sie den Abschnitt Structure of a Test Runner.
Dies ist keine Voraussetzung für das Schreiben eines neuen Test-Runners. Test-Runner können isoliert geschrieben werden.
Mindestanforderung: Schnittstelle implementieren
Um als Tradefed-Testrunner zu gelten, muss mindestens die IRemoteTest-Schnittstelle und insbesondere die run(TestInformation testInfo, ITestInvocationListener listener)-Methode implementiert werden.
Diese Methode wird vom Harness aufgerufen, wenn der Test-Runner verwendet wird, ähnlich wie bei einem Java-Runnable.
Jeder Teil dieser Methode wird als Teil der Ausführung des Test-Runners betrachtet.
Berichtsergebnisse vom Test-Runner
Die Methode run in der Basisschnittstelle bietet Zugriff auf ein Listener-Objekt vom Typ ITestInvocationListener. Dieses Objekt ist der Schlüssel, um strukturierte Ergebnisse vom Test-Runner an den Harness zu melden.
Wenn ein Testrunner strukturierte Ergebnisse meldet, hat er die folgenden Eigenschaften:
- Erstelle einen Bericht mit einer Liste aller ausgeführten Tests, der Dauer der einzelnen Tests und dem Ergebnis der einzelnen Tests (bestanden, fehlgeschlagen oder ein anderer Status).
- Berichten Sie gegebenenfalls Messwerte, die mit den Tests verknüpft sind, z. B. Messwerte zur Installationszeit.
- Die meisten Infrastrukturtools sind enthalten, z. B. zum Anzeigen von Ergebnissen und Messwerten.
- Die Fehlersuche ist in der Regel einfacher, da es einen detaillierteren Ablauf der Ausführung gibt.
Das Melden strukturierter Ergebnisse ist jedoch optional. Ein Test-Runner möchte möglicherweise nur den Status des gesamten Laufs als „PASSED“ oder „FAILED“ bewerten, ohne Details zur tatsächlichen Ausführung.
Die folgenden Ereignisse können für den Listener aufgerufen werden, um das Harness über den aktuellen Fortschritt der Ausführungen zu informieren:
- testRunStarted: Benachrichtigt über den Beginn einer Gruppe von zusammengehörigen Testläufen.
- testStarted: Benachrichtigt über den Beginn eines Testlaufs.
- testFailed/testIgnored: Benachrichtigen Sie über die Statusänderung des laufenden Testlaufs. Ein Testlauf ohne Statusänderung gilt als bestanden.
- testEnded: Benachrichtigt über das Ende des Testlaufs.
- testRunFailed: Benachrichtigt, dass der Gesamtstatus der Ausführung der Gruppe von Testläufen ein Fehler ist. Ein Testlauf kann bestanden oder fehlgeschlagen sein, unabhängig von den Ergebnissen der Testfälle, je nachdem, was bei der Ausführung erwartet wurde. Ein Binärprogramm, das mehrere Testläufe ausführt, könnte beispielsweise alle Testläufe mit dem Ergebnis Bestanden melden, aber mit einem Fehler-Exit-Code beendet werden (aus beliebigen Gründen, z. B. aufgrund von Lecks in Dateien).
- testRunEnded: Benachrichtigt über das Ende der Gruppe von Testläufen.
Die Aufrechterhaltung und Sicherstellung der richtigen Reihenfolge der Callbacks liegt in der Verantwortung des Testrunner-Implementierers. Er muss beispielsweise dafür sorgen, dass testRunEnded im Falle einer Ausnahme mit einer finally-Klausel aufgerufen wird.
Testlauf-Callbacks (testStarted, testEnded usw.) sind optional. Ein Testlauf kann ohne Testläufe erfolgen.
Sie werden feststellen, dass diese Ereignisstruktur an die typische JUnit-Struktur angelehnt ist. Das ist so gewollt, damit die Beispiele möglichst einfach gehalten werden und Entwickler sie nachvollziehen können.
Berichtsprotokolle vom Test-Runner
Wenn Sie Ihre eigene Tradefed-Testklasse oder Ihren eigenen Tradefed-Runner schreiben, implementieren Sie IRemoteTest und erhalten ein ITestInvocationListener über die Methode run(). Mit diesem Listener können Sie Dateien so protokollieren:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Mit einem Gerät testen
Die oben genannte Mindestschnittstelle ermöglicht das Ausführen sehr einfacher Tests, die isoliert sind und keine besonderen Ressourcen erfordern, z. B. Java-Einheitentests.
Testentwickler, die mit dem Gerätetest fortfahren möchten, benötigen die folgenden Schnittstellen:
- Mit IDeviceTest kann das
ITestDevice-Objekt empfangen werden, das das zu testende Gerät darstellt, und die API für die Interaktion mit dem Gerät bereitgestellt werden. - Mit IBuildReceiver kann der Test das
IBuildInfo-Objekt abrufen, das im Build-Provider-Schritt erstellt wurde und alle Informationen und Artefakte enthält, die sich auf die Testkonfiguration beziehen.
Test-Runner sind in der Regel an diesen Schnittstellen interessiert, um Artefakte im Zusammenhang mit der Ausführung zu erhalten, z. B. zusätzliche Dateien, und um das zu testende Gerät zu erhalten, das während der Ausführung verwendet wird.
Mit mehreren Geräten testen
Tradefed unterstützt die gleichzeitige Ausführung von Tests auf mehreren Geräten. Das ist nützlich, wenn Sie Komponenten testen, die eine externe Interaktion erfordern, z. B. das Koppeln eines Smartphones und einer Smartwatch.
Wenn Sie einen Test-Runner schreiben möchten, der mehrere Geräte verwenden kann, müssen Sie IMultiDeviceTest implementieren. Dadurch erhalten Sie eine Zuordnung von ITestDevice zu IBuildInfo, die die vollständige Liste der Gerätedarstellungen und der zugehörigen Build-Informationen enthält.
Der Setter der Schnittstelle wird immer vor der run-Methode aufgerufen. Sie können also davon ausgehen, dass die Struktur verfügbar ist, wenn run aufgerufen wird.
Tests, die ihre Einrichtung kennen
Einige Testrunner-Implementierungen benötigen möglicherweise Informationen zur Gesamteinrichtung, um ordnungsgemäß zu funktionieren, z. B. einige Metadaten zum Aufruf oder welche target_preparer zuvor ausgeführt wurden.
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 Testrunner-Implementierung müssen Sie IConfigurationReceiver implementieren, um das IConfiguration-Objekt zu empfangen.
Flexibler Test-Ausführer
Test-Runner können eine flexible Möglichkeit zum Ausführen von Tests bieten, wenn sie eine detaillierte Kontrolle darüber haben. Ein JUnit-Test-Runner kann beispielsweise jeden Unittest einzeln ausführen.
So kann das größere Harness und die Infrastruktur diese genaue Steuerung nutzen und Nutzer können den Testrunner teilweise über Filterung ausführen.
Die Filterunterstützung wird in der ITestFilterReceiver-Schnittstelle beschrieben. Damit können Gruppen von include- und exclude-Filtern für die Tests empfangen werden, die ausgeführt werden sollen oder nicht.
Ein Test wird nur 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 nicht mit einem der Ausschlussfilter übereinstimmen.