Tradefed-Test-Runner schreiben

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, Siehe 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 des Test-Runners melden

Die Methode run in der Basisschnittstelle ermöglicht Zugriff auf das Listener-Objekt von Geben Sie ITestInvocationListener ein. Dieses Objekt ist der Schlüssel zur strukturierten Berichterstellung. Ergebnisse vom Test-Runner an das Harness.

Durch die Meldung strukturierter Ergebnisse hat ein Test-Runner die folgenden Eigenschaften:

  • Erstellen Sie eine Liste aller durchgeführten Tests, wie lange sie gedauert haben und ob sie einzeln bestanden wurden, oder nicht bestanden wurden.
  • Geben Sie gegebenenfalls Messwerte für die Tests an, z. B. Messwerte zur Installationszeit.
  • Passen in die meisten Infrastrukturtools, zum Beispiel Anzeige von Ergebnissen und Metriken usw.
  • Die Fehlerbehebung ist in der Regel einfacher, da es einen detaillierteren Trace der Seite gibt. Ausführung.

Das Melden strukturierter Ergebnisse ist jedoch optional. könnte ein Test-Runner den Status der gesamten Ausführung als BESTANDEN oder FEHLGESCHLAGEN ohne Einzelheiten zur Ausführung zu dokumentieren.

Die folgenden Ereignisse können auf dem Listener aufgerufen werden, um das Netzwerk des aktuellen Fortschritt der Ausführungen:

  • testRunStarted: Benachrichtigung am Anfang einer Gruppe von Testläufen, die zusammengehören.
    • testStarted: Benachrichtigung zum Starten eines Testfalls.
    • testFailed/testIgnored: Benachrichtigt über den Statuswechsel des laufenden Testfalls. Es wird ein Testlauf ohne Statusänderung betrachtet bestanden.
    • testEnded: Benachrichtigt über das Ende des Testfalls.
  • testRunFailed: Benachrichtigen, dass der Gesamtstatus der Gruppe von Testläufen die Ausführung scheitert. Ein Testlauf kann erfolgreich oder fehlgeschlagen sein, unabhängig von den Ergebnissen der Testfälle, je nachdem, was bei der Ausführung erwartet wurde. Ein Binärprogramm mit mehreren Testläufen könnte alle bestandenen Testläufe melden, aber mit einem Fehler-Exit-Code (für alle Gründe: gehackte Dateien usw.).
  • testRunEnded: Benachrichtigt über das Ende der Gruppe von Testfällen.

Die Beibehaltung und Sicherstellung der korrekten Reihenfolge der Callbacks ist das des Test-Runner-Implementierers, z. B. dafür zu sorgen, testRunEnded wird im Ausnahmefall mit einer finally-Klausel aufgerufen.

Callbacks für Testfälle (testStarted, testEnded usw.) sind optional. Ein Test kann ohne Testläufe ausgeführt werden.

Diese Ereignisstruktur ist von der typischen JUnit-Struktur inspiriert. Das soll Entwicklern den Einstieg erleichtern.

Protokolle aus dem Test-Runner melden

Wenn Sie Ihre eigene Tradefed-Testklasse oder -Runner schreiben, implementieren Sie IRemoteTest und rufen Sie über die Methode run() ein ITestInvocationListener ab. 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 Mindestoberfläche oben ermöglicht die Ausführung sehr einfacher, isolierter Tests. und benötigen keine bestimmten Ressourcen, zum Beispiel Java-Unittests.

Tester, 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.
  • IBuildReceiver kann der Test das IBuildInfo-Objekt abrufen, das am Build-Provider-Schritt die alle Informationen und Artefakte im Zusammenhang mit der 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. Dies ist hilfreich beim Testen von Komponenten, die eine externe Interaktion erfordern, z. B. Smartphone und Smartwatch koppeln.

Um einen Test-Runner zu schreiben, der mehrere Geräte verwenden kann, benötigen Sie zur Implementierung der IMultiDeviceTest Damit kann eine Karte von ITestDevice zu IBuildInfo empfangen werden, die die vollständige Liste der Gerätedarstellungen und die zugehörigen Build-Informationen

Der Setter aus der Schnittstelle wird immer vor der run-Methode aufgerufen. Daher ist davon auszugehen, dass die Struktur verfügbar ist, wenn run aufgerufen wird.

Die Einrichtungen der Tests wurden erkannt

Für einige Test-Runner-Implementierungen sind möglicherweise Informationen zur Gesamteinrichtung erforderlich damit alles richtig funktioniert, zum Beispiel einige Metadaten zum Aufruf oder die target_preparer zuvor ausgeführt wurde usw.

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 Konfigurationsobjekt in der Beschreibung.

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 der größere Netzwerk- und Infrastrukturbereich diese feine Kontrolle und Nutzer können den Test-Runner teilweise über Filterung ausführen.

Die Filterunterstützung wird in der ITestFilterReceiver-Schnittstelle beschrieben. Damit können Sets von include- und exclude-Filtern für die Tests empfangen werden, die ausgeführt werden sollen oder nicht.

Gemäß unserer Konvention wird ein Test ausgeführt, wenn er einer oder mehreren der "Einschließen"-Filter UND stimmt mit keinem der "Ausschließen"-Filter überein. Falls nicht, füge -Filter angegeben sind, sollten alle Tests ausgeführt werden, solange sie keinem der zum Ausschließen.