Jeśli dopiero zaczynasz zajmować się programowaniem na platformę Android, ten kompletny przykład dodawania od podstaw nowego binarnego pliku GTest (czasem nazywanego „natywnym” testem) może być przydatny jako przykład typowego procesu. Więcej informacji o ramowcu GTest w języku C++ znajdziesz w dokumentacji na stronie projektu GTest.
W tym przewodniku używamy przykładowego testu 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 dedykowany podkatalog, który zawiera kod źródłowy komponentu.
Zakładając, że katalog główny źródła komponentu znajduje się w folderze <component source
root>, większość komponentów ma pod sobą 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 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 testsz powodu konieczności spakowania różnych zestawów testów do poszczególnych plików binarnych.
W tym przypadku musisz utworzyć nowy katalog podrzędny w folderze 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
\-- ...
A tak wygląda typowy schemat katalogu w przypadku 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ść pliku include jest automatycznie rozwiązywana za pomocą elementu BUILD_NATIVE_TEST w pliku make.
#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 na panelu wyników następującą 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 konfiguracji, który kieruje system 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 opartego na Soong. Więcej informacji znajdziesz w sekcji Prosta konfiguracja testu.
złożony plik konfiguracji,
Aby zamiast tego użyć usługi Trade Federation, napisz plik konfiguracji testu dla narzędzia testowego Trade Federation na Androida.
Konfiguracja testu może określać specjalne opcje konfiguracji urządzenia i domyślne argumenty do przekazania klasie testu.
Kompilowanie i testowanie lokalnie
W przypadku najczęstszych zastosowań użyj poświadczenia.
W bardziej złożonych przypadkach wymagających bardziej zaawansowanej personalizacji postępuj zgodnie z instrukcjami dotyczącymi implementacji.