Wenn Sie noch nicht mit der Entwicklung von Android-Plattformen vertraut sind, finden Sie hier Beispiel für das Hinzufügen eines brandneuen GTest-Binärprogramms (manchmal auch als „native“ Test) von Grund auf neu, um den typischen Arbeitsablauf zu demonstrieren. Für Weitere Informationen zum GTest-Framework für C++ finden Sie im GTest-Projekt weitere Informationen.
In dieser Anleitung wird der Hello World GTest verwendet. als Beispiel. Wir empfehlen, den Code zu lesen, um einen groben Überblick zu erhalten. bevor Sie fortfahren.
Quellspeicherort festlegen
In der Regel hat Ihr Team bereits ein festes Muster von Orten, die überprüft werden sollen. im Code und an Stellen, an denen Tests hinzugefügt werden können. Die meisten Teams haben ein einzelnes Git-Repository oder können Sie eines für andere Teams freigeben, haben aber ein eigenes Unterverzeichnis, das Quellcode der Komponente.
Angenommen, der Stammspeicherort Ihrer Komponentenquelle ist <component source
root>, dann haben die meisten Komponenten die Ordner src und tests darunter und einige zusätzliche Dateien wie Android.mk (oder sie sind in zusätzliche .bp-Dateien aufgeteilt).
Da Sie einen neuen Test hinzufügen, müssen Sie wahrscheinlich
tests neben der Komponente src und füllen Sie sie mit Inhalt.
In einigen Fällen hat Ihr Team möglicherweise weitere Verzeichnisstrukturen unter tests
da verschiedene Testsuiten in individuelle Binärdateien gepackt werden müssen.
Und in diesem Fall müssen Sie ein neues Unterverzeichnis unter tests erstellen.
Zur Verdeutlichung sehen Sie hier eine typische Verzeichnisstruktur für Komponenten mit einem einzelnen
Ordner „tests“:
\
<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 eine typische Verzeichnisstruktur für Komponenten mit mehreren Testquellen. Verzeichnisse:
\
<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
dem neu erstellten Unterverzeichnis mit Dateien, die denen im native ähneln
in der Gerrit-Änderung des Beispiels. In den folgenden Abschnitten erfahren Sie,
weitere Details zu den einzelnen Dateien.
Quellcode
Siehe Hello World GTest finden Sie ein Beispiel.
Der Quellcode für dieses Beispiel ist hier annotiert:
#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 Testfall.
und dann der Testname. Zusammen mit dem Testbinärnamen bilden sie den
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, das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Paketerstellung Anleitung. In den meisten Fällen ist die Option für die Blueprint-Datei auf Songbasis ausreichend. Weitere Informationen finden Sie unter Einfache Testkonfiguration.
Komplexe Konfigurationsdatei
Wenn Sie stattdessen die Handelsföderation verwenden möchten, schreiben Sie eine Testkonfiguration -Datei für das Android-Test-Harnisch Trade Federation.
In der Testkonfiguration können spezielle Geräteeinrichtungsoptionen und Standardeinstellungen für die Bereitstellung der Testklasse.
Lokal erstellen und testen
Für die häufigsten Anwendungsfälle Atest:
Bei komplexeren Fällen, die eine umfangreichere Anpassung erfordern, folgen Sie der Anleitung zur Instrumentierung.