Jeśli jesteś nowicjuszem w tworzeniu platformy Android, ten kompletny przykład dodania zupełnie nowego pliku binarnego GTest (czasami nazywanego również testem „natywnym”) od podstaw może okazać się przydatny do zademonstrowania typowego przepływu pracy. Aby uzyskać dodatkowe informacje na temat struktury GTest dla języka C++, zapoznaj się z witryną projektu GTest w celu uzyskania dodatkowej dokumentacji.
W tym przewodniku jako przykładu użyto testu Hello World GTest . Zalecamy przeczytanie kodu, aby uzyskać przybliżone zrozumienie przed kontynuowaniem.
Decydowanie o lokalizacji źródła
Zazwyczaj Twój zespół będzie miał już ustalony wzorzec miejsc do zaewidencjonowania kodu i miejsc do dodania testów. Większość zespołów posiada pojedyncze repozytorium git lub współdzieli je z innymi zespołami, 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 niektóre dodatkowe pliki, takie jak Android.mk (lub podzielone 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 do poszczególnych plików binarnych. W takim przypadku będziesz musiał utworzyć nowy podkatalog w obszarze tests .
Aby to zilustrować, oto typowy zarys katalogu 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 katalogu 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 zapełnisz katalog tests lub nowo utworzony podkatalog plikami podobnymi do tego, co znajduje się w katalogu native w przykładowej zmianie gerrit. Poniższe sekcje wyjaśnią 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 jest opisany tutaj:
#include <gtest/gtest.h>
Plik nagłówkowy zawiera GTest. Zależność pliku dołączania jest automatycznie rozwiązywana przy użyciu BUILD_NATIVE_TEST w pliku makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Testy GT są pisane przy użyciu makra TEST : pierwszy parametr to nazwa przypadku testowego, a drugi to nazwa testu. Wraz z nazwą pliku binarnego testu tworzą one następującą hierarchię na pulpicie nawigacyjnym 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 do kierowania systemem kompilacji z metadanymi modułu, zależnościami w czasie kompilacji i instrukcjami dotyczącymi pakowania. W większości przypadków opcja pliku Blueprint oparta na Soong jest wystarczająca. Aby uzyskać szczegółowe informacje, zobacz Prosta konfiguracja testu .
Złożony plik konfiguracyjny
Aby zamiast tego użyć Trade Federation, napisz testowy plik konfiguracyjny dla zestawu testowego Androida, Trade Federation .
Konfiguracja testu może określać specjalne opcje konfiguracji urządzenia i domyślne argumenty w celu dostarczenia klasy testowej.
Twórz i testuj lokalnie
W przypadku najczęstszych przypadków użycia zastosuj Atest .
W przypadku bardziej złożonych przypadków wymagających większego dostosowania postępuj zgodnie z instrukcjami dotyczącymi oprzyrządowania .