Wenn Sie neu in der Android-Plattformentwicklung sind, finden Sie dieses vollständige Beispiel für das Hinzufügen einer brandneuen GTest-Binärdatei (manchmal auch als „nativer“ Test bezeichnet) von Grund auf nützlich, um den typischen Arbeitsablauf zu demonstrieren. Weitere Informationen zum GTest-Framework für C++ finden Sie auf der GTest-Projektwebsite für zusätzliche Dokumentation.
Diese Anleitung verwendet den Hello World GTest als Beispiel. Wir empfehlen, den Code durchzulesen, um ihn grob zu verstehen, bevor Sie fortfahren.
Entscheidung für einen Quellort
In der Regel verfügt Ihr Team bereits über ein etabliertes Muster von Stellen zum Einchecken von Code und Stellen zum Hinzufügen von Tests. Die meisten Teams besitzen ein einzelnes Git-Repository oder teilen sich eines mit anderen Teams, haben aber ein dediziertes Unterverzeichnis, das den Quellcode der Komponenten enthält.
Angenommen, der Stammspeicherort für Ihre Komponentenquelle ist <component source root> , haben die meisten Komponenten die Ordner src und tests darunter und einige zusätzliche Dateien wie Android.mk (oder aufgeteilt in zusätzliche .bp Dateien).
Da Sie einen brandneuen Test hinzufügen, müssen Sie wahrscheinlich das Verzeichnis tests neben Ihrer Komponente src erstellen und es mit Inhalt füllen.
In einigen Fällen tests Ihr Team möglicherweise weitere Verzeichnisstrukturen, da verschiedene Testsuiten in einzelne Binärdateien gepackt werden müssen. Und in diesem Fall müssen Sie unter tests ein neues Unterverzeichnis erstellen.
Zur Veranschaulichung ist hier ein typischer Verzeichnisaufbau für Komponenten mit einem einzigen 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 eine typische Verzeichnisstruktur 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 werden Sie am Ende das tests Verzeichnis oder das neu erstellte Unterverzeichnis mit Dateien füllen, die denen im native Verzeichnis in der Beispiel-Gerrit-Änderung ähneln. In den folgenden Abschnitten werden weitere Einzelheiten zu jeder Datei erläutert.
Quellcode
Ein Beispiel finden Sie im Hello World GTest .
Der Quellcode für dieses Beispiel ist hier annotiert:
#include <gtest/gtest.h>
Header-Datei für GTest enthalten. Die Abhängigkeit der Include-Datei wird automatisch aufgelöst, indem BUILD_NATIVE_TEST im Makefile verwendet wird.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTests werden mit dem TEST Makro geschrieben: Der erste Parameter ist der Testfallname und der zweite der Testname. 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 über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierzeit und Paketierungsanweisungen zu steuern. In den meisten Fällen ist die Soong-basierte Blueprint-Dateioption ausreichend. Einzelheiten finden Sie unter Einfache Testkonfiguration .
Komplexe Konfigurationsdatei
Um stattdessen Trade Federation zu verwenden, schreiben Sie eine Testkonfigurationsdatei für die Testumgebung von Android, Trade Federation .
Die Testkonfiguration kann spezielle Geräteeinrichtungsoptionen und Standardargumente angeben, um die Testklasse bereitzustellen.
Erstellen und testen Sie lokal
Verwenden Sie für die häufigsten Anwendungsfälle Atest .
Für komplexere Fälle, die umfangreichere Anpassungen erfordern, befolgen Sie die Anweisungen zur Instrumentierung .