Google jest zaangażowany w promowanie równości rasowej dla społeczności czarnych. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Dodawanie nowego przykładu testu natywnego

Jeśli dopiero zaczynasz tworzyć platformę Android, ten kompletny przykład dodania zupełnie nowego testu natywnego od zera może być przydatny do zademonstrowania typowego przepływu pracy. Ponadto, jeśli nie znasz także frameworka gtest dla C ++, zapoznaj się z witryną projektu gtest, aby uzyskać dodatkową dokumentację.

Ten przewodnik używa następującego testu jako przykładu:

Hello World Native Test

Zaleca się najpierw przejrzeć kod, aby uzyskać ogólne wrażenie, zanim przejdziesz dalej.

Decydowanie o lokalizacji źródłowej

Zazwyczaj Twój zespół ma już ustalony wzorzec miejsc do wpisywania kodu i miejsc do dodawania testów. Większość zespołów posiada 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 katalogu głównego źródła komponentu to <component source root> , większość komponentów ma pod sobą foldery src i tests , a także niektóre dodatkowe pliki, takie jak Android.mk (lub podzielone na dodatkowe pliki .bp ).

Od dodajesz nowy test, prawdopodobnie będziesz musiał stworzyć tests katalogu obok składnika src , i wypełnić go treścią.

W niektórych przypadkach, Twój zespół może mieć dalsze struktury katalogów w ramach tests ze względu na konieczność zapakowania różnych apartamentów testów na poszczególne pliki binarne. W takim przypadku musisz utworzyć nowy podkatalog w ramach 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ódłowymi 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, 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. W poniższych sekcjach wyjaśniono bardziej szczegółowo każdy plik.

Kod źródłowy

Zobacz przykład Hello World Native Test .

Kod źródłowy z adnotacjami jest wymieniony poniżej:

 #include <gtest/gtest.h>
 

Plik nagłówkowy zawiera plik gtest. Zauważ, że 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!");
}
 

gtesty są zapisywane przy użyciu makra TEST : pierwszy parametr to nazwa przypadku testowego, a drugi to nazwa testu; wraz z nazwą binarną testu, po wizualizacji w dashboardzie wyników, tworzą poniższą hierarchię:

 <test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...
 

Więcej informacji na temat pisania testów za pomocą gtest znajdziesz w jego dokumentacji:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

Prosty plik konfiguracyjny

Każdy nowy moduł testowy musi mieć plik konfiguracyjny, aby kierować systemem kompilacji z metadanymi modułu, zależnościami czasu kompilacji i instrukcjami pakowania. W większości przypadków opcja pliku Blueprint oparta na Soong jest wystarczająca. Aby uzyskać szczegółowe informacje, patrz Prosta konfiguracja testu .

Złożony plik konfiguracyjny

Aby zamiast tego użyć Trade Federation, napisz testowy plik konfiguracyjny dla wiązki testowej Androida, Trade Federation .

Konfiguracja testowa może określać specjalne opcje konfiguracji urządzenia i domyślne argumenty w celu dostarczenia klasy testowej.

Twórz i testuj lokalnie

W najczęstszych przypadkach użyj Atest .

W przypadku bardziej złożonych przypadków wymagających bardziej szczegółowego dostosowania postępuj zgodnie z instrukcjami oprzyrządowania .