Dodaj nowe testy Google (GTests)

Jeśli dopiero zaczynasz przygodę z tworzeniem platformy Android, ten kompletny przykład dodania od podstaw zupełnie nowego pliku binarnego GTest (czasami nazywanego także „testem natywnym”) może okazać się przydatny w celu zademonstrowania typowego przepływu pracy. Dodatkowe informacje na temat platformy GTest dla języka C++ można znaleźć w witrynie projektu GTest , gdzie znajduje się dodatkowa dokumentacja.

W tym przewodniku jako przykład wykorzystano test Hello World GTest . Zalecamy przeczytanie kodu, aby uzyskać jego ogólne zrozumienie przed kontynuowaniem.

Zdecyduj się na lokalizację źródłową

Zazwyczaj Twój zespół będzie już miał ustalony wzorzec miejsc do sprawdzania kodu i miejsc do dodawania testów. Większość zespołów posiada jedno repozytorium git lub udostępnia je innym zespołom, ale ma dedykowany podkatalog zawierający kod źródłowy komponentu.

Zakładając, że lokalizacja główna źródła komponentu to <component source root> , większość komponentów ma pod sobą foldery src i tests oraz kilka dodatkowych plików, takich jak Android.mk (lub podzielonych na dodatkowe pliki .bp ).

Ponieważ dodajesz zupełnie nowy test, prawdopodobnie będziesz musiał utworzyć katalog tests obok swojego komponentu src i wypełnić go treścią.

W niektórych przypadkach Twój zespół może tests dalsze struktury katalogów ze względu na potrzebę spakowania różnych zestawów testów w osobne pliki binarne. W tym przypadku będziesz musiał utworzyć nowy podkatalog w ramach tests .

Aby to zilustrować, oto typowy schemat katalogów dla komponentów z jednym folderem 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
          \-- ...

a oto typowy zarys katalogów dla komponentów z wieloma katalogami źródeł testów:

\
 <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
      |       \-- ...
      \-- ...

Niezależnie od struktury, w końcu zapełnisz katalog tests lub nowo utworzony podkatalog plikami podobnymi do tego, co znajduje się w katalogu native w przykładowej zmianie gerrit. W poniższych sekcjach wyjaśniono bardziej szczegółowo każdy plik.

Kod źródłowy

Przykład można znaleźć w Hello World GTest .

Kod źródłowy tego przykładu znajduje się tutaj:

#include <gtest/gtest.h>

Dołącz plik nagłówkowy dla GTest. Zależność pliku dołączanego jest automatycznie rozwiązywana przy użyciu BUILD_NATIVE_TEST w pliku makefile.

#include <stdio.h>

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

GTests pisze się za pomocą makra TEST : pierwszy parametr to nazwa przypadku testowego, drugi to nazwa testu. Wraz z nazwą binarną testu tworzą one następującą hierarchię w panelu wyników:

<test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...

Więcej informacji na temat pisania testów za pomocą GTest znajdziesz w dokumentacji GTest

Prosty plik konfiguracyjny

Każdy nowy moduł testowy musi mieć plik konfiguracyjny, który będzie sterował systemem kompilacji za pomocą metadanych modułu, zależności w czasie kompilacji i instrukcji pakowania. W większości przypadków wystarczająca jest opcja pliku Blueprint oparta na Song. Aby uzyskać szczegółowe informacje, zobacz Prosta konfiguracja testu .

Złożony plik konfiguracyjny

Aby zamiast tego skorzystać z Federacji Handlowej, napisz plik konfiguracji testowej dla wiązki testowej Androida, Federacja Handlowa .

Konfiguracja testowa może określać specjalne opcje konfiguracji urządzenia i domyślne argumenty dostarczające klasę testową.

Kompiluj i testuj lokalnie

W najczęstszych przypadkach użycia użyj Atest .

W przypadku bardziej złożonych przypadków wymagających większego dostosowania należy postępować zgodnie z instrukcjami dotyczącymi oprzyrządowania .