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 .