Dodaj nowe testy GoogleTests (GTests)

Jeśli nie masz doświadczenia w programowaniu na platformie Android, ten przykład dodania zupełnie nowego pliku binarnego GTest (czasem nazywanego też testem natywnym) może okazać się przydatny i zademonstrować typowy przepływ pracy. Więcej informacji o ramowcu GTest w języku C++ znajdziesz w dokumentacji na stronie projektu GTest.

W tym przewodniku użyto narzędzia Hello World GTest. Zanim przejdziesz dalej, zalecamy zapoznanie się z kodem.

Wybierz lokalizację źródłową

Zespół ma zwykle ustalony schemat miejsc, w których należy sprawdzić kod, oraz miejsc, w których należy dodać testy. Większość zespołów ma jedno repozytorium Git lub udostępnia je innym zespołom, ale ma specjalny podkatalog, który zawiera kod źródłowy komponentu.

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

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

W niektórych przypadkach Twój zespół może mieć dodatkowe struktury katalogów w folderze tests, ponieważ trzeba spakować różne zestawy testów w osobne pliki binarne. W tym przypadku musisz utworzyć nowy podkatalog w katalogu tests.

Poniżej przedstawiamy typowy schemat folderu 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
          \-- ...

Oto typowy schemat katalogu 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, katalog tests lub nowo utworzony podkatalog wypełnisz plikami podobnymi do tych, które znajdują się w katalogu native w przykładowej zmianie w Gerricie. W sekcjach poniżej znajdziesz więcej informacji o każdym pliku.

Kod źródłowy

Przykładem jest Hello World GTest.

Kod źródłowy tego przykładu jest opatrzony adnotacjami:

#include <gtest/gtest.h>

Plik nagłówka dołączany do GTest. Zależność między plikiem uwzględniania jest rozwiązywana automatycznie za pomocą polecenia BUILD_NATIVE_TEST w pliku Makefile.

#include <stdio.h>

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

Testy G są pisane za pomocą makra TEST: pierwszy parametr to nazwa przypadku testowego, a drugi to nazwa testu. Wraz z nazwą testu binarnego tworzą one w panelu wyników taką hierarchię:

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

Więcej informacji o tworzeniu testów za pomocą GTest znajdziesz w dokumentacji GTest.

Prosty plik konfiguracji

Każdy nowy moduł testowy musi mieć plik konfiguracji, który przekazuje do systemu kompilacji metadane modułów, zależności czasu kompilowania i instrukcje tworzenia pakietów. W większości przypadków wystarczająca jest opcja pliku Blueprint na podstawie Soong. Szczegółowe informacje znajdziesz w sekcji Prosta konfiguracja testu.

Złożony plik konfiguracji

Aby zamiast tego użyć Trade Federation, napisz plik konfiguracji testów dla testowego zestawu narzędzi Androida Trade Federation.

Konfiguracja testu może określać specjalne opcje konfiguracji urządzenia i domyślne argumenty, które mają być przekazywane do klasy testu.

Kompilowanie i testowanie lokalnie

W najczęstszych przypadkach użyj Atest.

W bardziej skomplikowanych przypadkach wymagających bardziej zaawansowanej personalizacji postępuj zgodnie z instrukcjami dotyczącymi implementacji.