Jeśli nie masz doświadczenia w programowaniu na platformie Android, ten artykuł może być kompletny przykład dodania zupełnie nowego pliku binarnego GTest (nazywanego też testu) od zera, przydatne do zademonstrowania typowego przepływu pracy. Dla: zawiera dodatkowe informacje na temat platformy GTest C++, patrz projekt GTest .
W tym przewodniku używany jest Hello World GTest. . Zalecamy przeczytanie kodu w celu jego przybliżenia zanim przejdziesz dalej.
Wybierz lokalizację źródłową
Zwykle Twój zespół ma już ustalony wzór miejsc do sprawdzenia w kodzie i miejscach, w których można 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 główna lokalizacja źródła komponentu znajduje się w lokalizacji <component source
root>, większość komponentów ma pod nim foldery src i tests, a niektóre
dodatkowych plików, takich jak Android.mk (lub podzielonych 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ć w folderze tests dodatkowe struktury katalogów ze względu na konieczność spakowania różnych zestawów testów do poszczególnych plików binarnych.
W tym przypadku musisz utworzyć nowy podkatalog w katalogu tests.
Oto typowy schemat katalogu dla komponentów z jednym
Folder 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 schemat katalogu dla komponentów z wieloma źródłami testowymi. katalogi:
\
<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
Zapoznaj się z testem Hello World. .
Oto adnotacja do kodu źródłowego tego przykładu:
#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 makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Testy GTest są zapisywane za pomocą makra TEST: pierwszy parametr to przypadek testowy
nazwa, a druga to nazwa testu. Wraz z nazwą pliku binarnego testu tworzą one
tę 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 o tworzeniu testów za pomocą GTest znajdziesz w dokumentacji GTest.
Prosty plik konfiguracji
Każdy nowy moduł testowy musi zawierać plik konfiguracji, który umożliwia system kompilacji z metadanymi modułów, zależnościami czasu kompilowania oraz sposobem pakietu, za instrukcje. W większości przypadków wystarczająca jest opcja pliku Blueprint na podstawie Soong. Szczegółowe informacje 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 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 najczęstszych przypadkach użycia Atest.
W przypadku bardziej złożonych przypadków, które wymagają większych dostosowań, postępuj zgodnie z instrumentacji.