Wenn Sie noch keine Erfahrung mit der Android-Plattformentwicklung haben, ist dieses vollständige Beispiel zum Hinzufügen einer neuen GTest-Binärdatei (manchmal auch als „nativer“ Test bezeichnet) von Grund auf hilfreich, um den typischen Workflow zu veranschaulichen. Weitere Informationen zum GTest-Framework für C++ finden Sie auf der GTest-Projekt website.
In dieser Anleitung wird der Hello World GTest als Beispiel verwendet. Wir empfehlen, den Code durchzulesen, um ein grobes Verständnis dafür zu erhalten, bevor Sie fortfahren.
Quellort auswählen
Normalerweise hat Ihr Team bereits ein etabliertes Muster von Orten, an denen Code eingecheckt und Tests hinzugefügt werden. Die meisten Teams haben ein einzelnes Git-Repository oder teilen sich eines mit anderen Teams, haben aber ein eigenes Unterverzeichnis mit dem Quellcode der Komponente.
Wenn der Stammort für den Quellcode Ihrer Komponente <component source
root> ist, haben die meisten Komponenten die Ordner src und tests darunter sowie einige
zusätzliche Dateien wie Android.mk (oder aufgeteilt in zusätzliche .bp
Dateien).
Da Sie einen neuen Test hinzufügen, müssen Sie wahrscheinlich das Verzeichnis tests neben dem src-Verzeichnis Ihrer Komponente erstellen und mit Inhalten füllen.
In einigen Fällen hat Ihr Team möglicherweise weitere Verzeichnisstrukturen unter tests, da verschiedene Testsuiten in einzelnen Binärdateien verpackt werden müssen.
In diesem Fall müssen Sie ein neues Unterverzeichnis unter tests erstellen.
Hier ist ein typischer Verzeichnisüberblick 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
\-- ...
Und hier ist ein typischer Verzeichnisüberblick 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>
Headerdatei für GTest. Die Abhängigkeit der Include-Datei wird automatisch mit 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 Testfalls und der zweite der Name des Tests. Zusammen mit dem Namen der Testbinä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, Kompilierzeitabhängigkeiten und Verpackungsanweisungen zu versorgen. In den meisten Fällen reicht die Soong-basierte Blueprint-Dateioption aus. Weitere Informationen finden Sie unter Einfache Testkonfiguration.
Komplexe Konfigurationsdatei
Wenn Sie stattdessen Trade Federation verwenden möchten, schreiben Sie eine Testkonfiguration datei für die Testplattform von Android, Trade Federation.
In der Testkonfiguration können spezielle Optionen für die Geräteeinrichtung und Standardargumente für die Testklasse angegeben werden.
Build lokal erstellen und testen
Für die häufigsten Anwendungsfälle verwenden Sie Atest.
Für komplexere Fälle, die eine stärkere Anpassung erfordern, folgen Sie der Anleitung zur Instrumentierung.