Jeśli dopiero zaczynasz tworzyć aplikacje na platformę Android, ten kompletny przykład dodawania od zera nowego pliku binarnego GTest (nazywanego też czasami testem „natywnym”) może Ci pomóc w poznaniu typowego procesu. Więcej informacji o platformie GTest dla C++ znajdziesz na stronie projektu GTest.
W tym przewodniku jako przykładu używamy testu GTest „Hello World”. Zanim przejdziesz dalej, zalecamy zapoznanie się z kodem, aby uzyskać ogólne pojęcie o jego działaniu.
Wybierz lokalizację źródłową
Zazwyczaj zespół ma już ustalone miejsca, w których należy sprawdzać kod, i miejsca, w których należy dodawać testy. Większość zespołów ma 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 w niej foldery src i tests oraz dodatkowe pliki, takie jak Android.mk (lub podzielone na dodatkowe pliki .bp).
Ponieważ dodajesz zupełnie nowy test, prawdopodobnie musisz utworzyć katalog testsobok komponentusrc i wypełnić go treścią.
W niektórych przypadkach zespół może mieć dodatkowe struktury katalogów w folderze tests
ze względu na konieczność spakowania różnych zestawów testów do osobnych plików binarnych.
W takim przypadku musisz utworzyć nowy podkatalog w tests.
Oto typowy zarys katalogu komponentów z 1 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 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 katalogu tests lub w nowo utworzonym podkatalogu znajdą się pliki podobne do tych, które znajdują się w katalogu tests w przykładowej zmianie Gerrit.native W sekcjach poniżej znajdziesz szczegółowe informacje o każdym pliku.
Kod źródłowy
Przykład znajdziesz w teście GTest Hello World.
Kod źródłowy tego przykładu jest tu opatrzony adnotacjami:
#include <gtest/gtest.h>
Plik nagłówkowy dołączony do GTest. Zależność pliku dołączanego jest automatycznie rozwiązywana przez użycie BUILD_NATIVE_TEST w pliku makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Testy GTest są pisane przy użyciu makra TEST: pierwszym parametrem jest nazwa przypadku testowego, a drugim – nazwa testu. Wraz z nazwą pliku binarnego testu tworzą w panelu wyników tę hierarchię:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
Więcej informacji o pisaniu testów za pomocą GTest znajdziesz w dokumentacji GTest.
Prosty plik konfiguracji
Każdy nowy moduł testowy musi mieć plik konfiguracyjny, który zawiera metadane modułu, zależności w czasie kompilacji i instrukcje pakowania, aby kierować systemem kompilacji. W większości przypadków wystarczy opcja oparta na Soongu, czyli plik Blueprint. Więcej informacji znajdziesz w artykule Prosta konfiguracja testu.
Złożony plik konfiguracji
Jeśli chcesz użyć Trade Federation, napisz plik konfiguracji testu dla jarzma testowego 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 przypadku najczęstszych zastosowań używaj funkcji Atest.
W bardziej złożonych przypadkach wymagających większego dostosowania postępuj zgodnie z instrukcjami dotyczącymi implementacji.