Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Hinzufügen eines neuen nativen Testbeispiels

Wenn Sie mit der Entwicklung von Android-Plattformen noch nicht vertraut sind, ist dieses vollständige Beispiel für das Hinzufügen eines brandneuen nativen Tests von Grund auf hilfreich, um den typischen Workflow zu demonstrieren. Wenn Sie mit dem gtest-Framework für C ++ nicht vertraut sind, lesen Sie bitte die gtest-Projektwebsite, um zusätzliche Dokumentation zu erhalten.

In diesem Handbuch wird der folgende Test als Beispiel verwendet:

Hallo World Native Test

Es wird empfohlen, zuerst den Code zu durchsuchen, um einen groben Eindruck zu erhalten, bevor Sie fortfahren.

Entscheidung für einen Quellort

In der Regel verfügt Ihr Team bereits über ein festgelegtes Muster von 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 Komponente enthält.

Unter der Annahme , das Stammverzeichnis für die Komponentenquelle ist bei <component source root> , die meisten Komponenten src und tests Ordner unter ihm, und einige zusätzliche Dateien wie Android.mk (oder aufgebrochen in zusätzliche .bp - Dateien).

Da Sie einen brandneuen Test hinzufügen, müssen Sie wahrscheinlich das tests neben Ihrer Komponente src erstellen und mit Inhalt src .

In einigen Fällen werden in Ihrem Team möglicherweise weitere Verzeichnisstrukturen tests 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 hier ein typisches Verzeichnis Entwurf für Komponenten mit einem einzigen tests Ordnern:

 \
 <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 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 das Bevölkern am Ende tests Verzeichnis oder das neu erstellte Unterverzeichnis mit Dateien ähnlich zu dem, was in native Verzeichnis in der Probe gerrit ändern. In den folgenden Abschnitten werden die einzelnen Dateien ausführlicher erläutert.

Quellcode

Ein Beispiel finden Sie im Hello World Native Test .

Der kommentierte Quellcode ist unten aufgeführt:

 #include <gtest/gtest.h>
 

Header-Datei enthalten für gtest. Beachten Sie, dass die Abhängigkeit von Include-Dateien automatisch mithilfe von BUILD_NATIVE_TEST im Makefile aufgelöst wird

 #include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}
 

gtests werden mithilfe des TEST Makros geschrieben: Der erste Parameter ist der Testfallname und der zweite der Testname. Zusammen mit dem Test-Binärnamen bilden sie die folgende Hierarchie, wenn sie im Ergebnis-Dashboard angezeigt werden:

 <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 Dokumentation:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

Einfache Konfigurationsdatei

Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Packungsanweisungen zu steuern. In den meisten Fällen ist die Option Soong-basierte Blueprint-Datei ausreichend. Weitere Informationen finden Sie unter Einfache Testkonfiguration .

Komplexe Konfigurationsdatei

Um stattdessen Trade Federation zu verwenden, schreiben Sie eine Testkonfigurationsdatei für das Testkabel von Android, Trade Federation .

In der Testkonfiguration können spezielle Geräte-Setup-Optionen und Standardargumente angegeben werden, um die Testklasse bereitzustellen.

Lokal erstellen und testen

Verwenden Sie für die häufigsten Anwendungsfälle Atest .

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