Wenn Sie noch nicht mit der Entwicklung für die Android-Plattform vertraut sind, ist dieses vollständige Beispiel für das Hinzufügen einer neuen GTest-Binärdatei (manchmal auch als „nativer“ Test bezeichnet) von Grund auf möglicherweise hilfreich, um den typischen Workflow zu veranschaulichen. Weitere Informationen zum GTest-Framework für C++ finden Sie in der Dokumentation auf der GTest-Projektwebsite.
In dieser Anleitung wird Hello World GTest als Beispiel verwendet. Wir empfehlen, den Code durchzulesen, um sich einen groben Überblick zu verschaffen, bevor Sie fortfahren.
Quellspeicherort auswählen
Normalerweise hat Ihr Team bereits ein etabliertes Muster für Orte, an denen Code geprüft und Tests hinzugefügt werden. Die meisten Teams haben ein eigenes Git-Repository oder teilen sich eines mit anderen Teams, haben aber ein eigenes Unterverzeichnis, das den Quellcode der Komponente enthält.
Angenommen, der Stammordner für den Quellcode Ihrer Komponente befindet sich unter <component source
root>. Die meisten Komponenten haben darunter die Ordner src und tests sowie einige zusätzliche Dateien wie Android.mk (oder aufgeteilt in zusätzliche .bp-Dateien).
Da Sie einen völlig neuen Test hinzufügen, müssen Sie wahrscheinlich das Verzeichnis tests neben Ihrer Komponente src erstellen und mit Inhalt füllen.
In einigen Fällen hat Ihr Team möglicherweise weitere Verzeichnisstrukturen unter tests, da verschiedene Testgruppen in einzelne Binärdateien gepackt werden müssen.
In diesem Fall müssen Sie ein neues Unterverzeichnis unter tests erstellen.
Hier ist ein typischer Verzeichnisbaum für Komponenten mit einem einzelnen tests-Ordner:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
Hier ist ein typischer Verzeichnisbaum für Komponenten mit mehreren Testquellverzeichnissen:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
Unabhängig von der Struktur füllen Sie das Verzeichnis tests oder das neu erstellte Unterverzeichnis mit Dateien, die denen im Verzeichnis native in der Beispiel-Gerrit-Änderung ähneln. In den folgenden Abschnitten werden die einzelnen Dateien genauer erläutert.
Quellcode
Ein Beispiel finden Sie unter Hello World GTest.
Der Quellcode für dieses Beispiel ist hier mit Anmerkungen versehen:
#include <gtest/gtest.h>
Header-Datei für GTest. Die Abhängigkeit der Include-Datei wird automatisch mithilfe von BUILD_NATIVE_TEST in der Make-Datei aufgelöst.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTests werden mit dem Makro TEST geschrieben. Der erste Parameter ist der Name des Testlaufs und der zweite der Name des Tests. Zusammen mit dem Namen der Test-Binärdatei bilden sie die folgende Hierarchie im Ergebnis-Dashboard:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
Weitere Informationen zum Schreiben von Tests mit GTest finden Sie in der GTest-Dokumentation.
Einfache Konfigurationsdatei
Jedes neue Testmodul muss eine Konfigurationsdatei haben, um das Build-System mit Modulmetadaten, Compile-Time-Abhängigkeiten und Verpackungsanweisungen zu versorgen. In den meisten Fällen ist die Soong-basierte Blueprint-Dateioption ausreichend. Weitere Informationen finden Sie unter Einfache Testkonfiguration.
Komplexe Konfigurationsdatei
Wenn Sie stattdessen Trade Federation verwenden möchten, schreiben Sie eine Testkonfigurationsdatei für die Testumgebung von Android, Trade Federation.
In der Testkonfiguration können spezielle Optionen für die Geräteeinrichtung und Standardargumente für die Testklasse angegeben werden.
Lokal erstellen und testen
Verwenden Sie für die häufigsten Anwendungsfälle Atest.
Bei komplexeren Fällen, die eine stärkere Anpassung erfordern, folgen Sie der Anleitung zur Instrumentierung.