Wenn Sie noch keine Erfahrung mit der Entwicklung für die Android-Plattform haben, kann Ihnen dieses vollständige Beispiel zum Hinzufügen einer brandneuen GTest-Binärdatei (manchmal auch als „nativer“ Test bezeichnet) von Grund auf helfen, den typischen Workflow zu veranschaulichen. Weitere Informationen zum GTest-Framework für C++ finden Sie in der GTest-Projektwebsite.
In diesem Leitfaden wird der Hello World-GTest als Beispiel verwendet. Wir empfehlen, den Code zu lesen, um sich ein grobes Bild davon zu machen, bevor Sie fortfahren.
Quellspeicherort festlegen
Normalerweise hat Ihr Team bereits ein etabliertes Muster für Stellen, an denen der Code geprüft und Tests hinzugefügt werden sollen. Die meisten Teams haben ein einzelnes Git-Repository oder teilen sich eines mit anderen Teams, haben aber ein eigenes Unterverzeichnis, das den Quellcode der Komponenten enthält.
Angenommen, der Stammspeicherort Ihrer Komponentenquelle ist <component source
root>. Die meisten Komponenten haben dann die Ordner src und tests und einige zusätzliche Dateien wie Android.mk (oder sind in zusätzliche .bp-Dateien aufgeteilt).
Da Sie einen brandneuen Test hinzufügen, müssen Sie wahrscheinlich das Verzeichnis tests neben Ihrer Komponente src erstellen und mit Inhalten füllen.
In einigen Fällen hat Ihr Team unter tests möglicherweise weitere Verzeichnisstrukturen, da verschiedene Testpakete in einzelne Binärdateien verpackt werden müssen.
In diesem Fall müssen Sie unter tests ein neues Unterverzeichnis erstellen.
Hier ist ein typisches Verzeichnis 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 Verzeichnis-Überblick für Komponenten mit mehreren Testquellenverzeichnissen:
\
<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 näher erläutert.
Quellcode
Ein Beispiel finden Sie im Hello World-GTest.
Der Quellcode für dieses Beispiel ist hier kommentiert:
#include <gtest/gtest.h>
Headerdatei für GTest Die Abhängigkeit der Include-Datei wird automatisch durch die Verwendung von BUILD_NATIVE_TEST im Makefile 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 Testname. Zusammen mit dem Namen des Testbinärprogramms bilden sie im Ergebnisdashboard die folgende Hierarchie:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
Weitere Informationen zum Erstellen von Tests mit GTest finden Sie in der GTest-Dokumentation.
Einfache Konfigurationsdatei
Jedes neue Testmodul muss eine Konfigurationsdatei haben, um das Buildsystem mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Verpackungsanweisungen zu steuern. 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 den Test-Harness 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 umfangreichere Anpassung erfordern, folgen Sie der Anleitung zur Instrumentierung.