Neue GoogleTests (GTests) hinzufügen

Wenn Sie neu in der Entwicklung von Android-Plattformen sind, finden Sie möglicherweise dieses vollständige Beispiel für das Hinzufügen einer brandneuen GTest-Binärdatei (manchmal auch als „nativer“ Test bezeichnet) von Grund auf hilfreich, um den typischen Arbeitsablauf zu veranschaulichen. Weitere Informationen zum GTest-Framework für C++ finden Sie auf der GTest-Projektseite mit zusätzlicher Dokumentation.

In diesem Leitfaden wird der Hello World GTest als Beispiel verwendet. Wir empfehlen, den Code durchzulesen, um ein grobes Verständnis davon zu erlangen, bevor Sie fortfahren.

Entscheiden Sie sich für einen Quellstandort

Normalerweise verfügt Ihr Team bereits über ein etabliertes Muster an Orten zum Einchecken von Code und Orten zum Hinzufügen von Tests. Die meisten Teams besitzen ein einzelnes Git-Repository oder teilen eines mit anderen Teams, verfügen jedoch über ein dediziertes Unterverzeichnis, das den Quellcode der Komponenten enthält.

Vorausgesetzt, dass sich der Stammspeicherort Ihrer Komponentenquelle bei <component source root> befindet, befinden sich unter den meisten Komponenten die Ordner src “ und tests sowie 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 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. In diesem Fall müssen Sie unter tests ein neues Unterverzeichnis erstellen.

Zur Veranschaulichung finden Sie hier eine typische Verzeichnisübersicht für Komponenten mit einem einzigen 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
          \-- ...

und hier ist eine typische Verzeichnisübersicht 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 werden Sie am Ende das tests 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 die einzelnen Dateien ausführlicher erläutert.

Quellcode

Ein Beispiel finden Sie im Hello World GTest .

Der Quellcode für dieses Beispiel ist hier kommentiert:

#include <gtest/gtest.h>

Header-Datei-Include für GTest. Die Abhängigkeit von der Include-Datei wird automatisch durch die Verwendung BUILD_NATIVE_TEST im Makefile aufgelöst.

#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 Binärnamen des Tests 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 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

Um stattdessen Trade Federation zu verwenden, schreiben Sie eine Testkonfigurationsdatei für Androids Testumgebung Trade Federation .

Die Testkonfiguration kann spezielle Geräte-Setup-Optionen und Standardargumente zur Bereitstellung der Testklasse angeben.

Lokal erstellen und testen

Für die häufigsten Anwendungsfälle verwenden Sie Atest .

Befolgen Sie bei komplexeren Fällen, die eine umfassendere Anpassung erfordern, die Anweisungen zur Instrumentierung .