Jeśli dopiero zaczynasz zajmować się tworzeniem aplikacji 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 jako przykład posłużyliśmy sobie testu GTest „Hello World”. 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 też specjalny podkatalog z kodem źródłowym komponentu.
Zakładając, że katalog główny źródła komponentu znajduje się w folderze <component source
root>, większość komponentów ma podfoldery 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.
Oto typowy schemat katalogu 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ą pliku binarnego testu tworzą na 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 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 na podstawie Soong. Więcej informacji znajdziesz w sekcji Prosta konfiguracja testu.
złożony plik konfiguracji,
Aby zamiast tego użyć architektury Trade Federation, napisz plik konfiguracji testów dla testowego zestawu narzędzi Trade Federation na potrzeby Androida.
Konfiguracja testu może określać specjalne opcje konfiguracji urządzenia i domyślne argumenty do przekazania do klasy testu.
Kompilowanie i testowanie lokalnie
W przypadku najczęstszych zastosowań użyj poświadczenia.
W bardziej złożonych przypadkach wymagających bardziej zaawansowanych dostosowań postępuj zgodnie z instrukcjami dotyczącymi implementacji.