Dodawanie nowych testów Google (GTests)

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Jeśli jesteś nowy w programowaniu platformy Android, ten kompletny przykład dodawania zupełnie nowego pliku binarnego Gtest (czasem nazywanego także testem „natywnym”) od podstaw może być przydatny do zademonstrowania typowego przepływu pracy. Dodatkowe informacje na temat struktury GTest dla C++ można znaleźć w witrynie projektu GTest w celu uzyskania dodatkowej dokumentacji.

W tym przewodniku jako przykładu użyto testu Hello World GTest . Zalecamy przeczytanie kodu, aby uzyskać zgrubne zrozumienie przed kontynuowaniem.

Decydowanie o lokalizacji źródłowej

Zazwyczaj Twój zespół ma już ustalony wzorzec miejsc, w których można sprawdzić kod i miejsca, w których można dodawać testy. Większość zespołów posiada pojedyncze repozytorium git lub udostępnia je innym zespołom, ale ma dedykowany podkatalog, który zawiera kod źródłowy komponentu.

Zakładając, że lokalizacja główna źródła komponentu znajduje się w <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 tests , prawdopodobnie będziesz musiał utworzyć katalog testing obok twojego komponentu src i wypełnić go treścią.

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

Aby to zilustrować, oto typowy zarys katalogów dla komponentów z pojedynczym 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ł testowych:

\
 <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 tests katalog testing lub nowo utworzony podkatalog plikami podobnymi do tego, co znajduje się w katalogu native w przykładowej zmianie gerrita. Poniższe sekcje wyjaśniają dalsze szczegóły każdego pliku.

Kod źródłowy

Zapoznaj się z testem Hello World GTest , aby zapoznać się z przykładem.

Kod źródłowy tego przykładu jest opisany tutaj:

#include <gtest/gtest.h>

Plik nagłówkowy zawiera dla GTest. Zależność pliku dołączanego jest automatycznie rozwiązywana za pomocą BUILD_NATIVE_TEST w pliku makefile.

#include <stdio.h>

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

Testy GT są zapisywane przy użyciu makra TEST : pierwszy parametr to nazwa przypadku testowego, a drugi to nazwa testu. Wraz z testową nazwą binarną tworzą 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>
|
...

Aby uzyskać więcej informacji na temat pisania testów za pomocą GTest, zapoznaj się z dokumentacją GTest

Prosty plik konfiguracyjny

Każdy nowy moduł testowy musi mieć plik konfiguracyjny kierujący systemem kompilacji z metadanymi modułu, zależnościami czasu kompilacji i instrukcjami pakowania. W większości przypadków wystarcza opcja pliku Blueprint opartego na Soong. Zobacz Prosta konfiguracja testu , aby uzyskać szczegółowe informacje.

Złożony plik konfiguracyjny

Aby zamiast tego użyć 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, aby dostarczyć klasę testową.

Twórz i testuj lokalnie

W najczęstszych przypadkach użyj Atest .

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