Добавить новые GoogleTests (GTests)

Если вы новичок в разработке приложений для Android, этот полный пример добавления нового исполняемого файла GTest (иногда называемого «нативным» тестом) с нуля может оказаться вам полезным для демонстрации типичного рабочего процесса. Дополнительную информацию о фреймворке GTest для C++ можно найти на сайте проекта GTest .

В этом руководстве в качестве примера используется Hello World GTest . Рекомендуем прочитать код, чтобы получить общее представление о нём, прежде чем продолжить.

Определите местоположение источника

Как правило, у вашей команды уже есть устоявшийся шаблон мест для добавления кода и добавления тестов. Большинство команд используют один Git-репозиторий или делят его с другими командами, но при этом имеют отдельный подкаталог с исходным кодом компонентов.

Если предположить, что корневое расположение исходного кода компонента находится в <component source root> , то у большинства компонентов внутри есть папки src и tests , а также некоторые дополнительные файлы, такие как Android.mk (или разбитые на дополнительные файлы .bp ).

Поскольку вы добавляете совершенно новый тест, вам, вероятно, потребуется создать каталог tests рядом с компонентом src и заполнить его содержимым.

В некоторых случаях вашей команде могут потребоваться дополнительные структуры каталогов в разделе tests , поскольку необходимо упаковать различные наборы тестов в отдельные двоичные файлы. В этом случае вам потребуется создать новый подкаталог в каталоге tests .

Для иллюстрации приведем типичную структуру каталога для компонентов с одной папкой 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
          \-- ...

а вот типичная структура каталога для компонентов с несколькими каталогами исходных тестовых данных:

\
 <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
      |       \-- ...
      \-- ...

Независимо от структуры, в конечном итоге вы заполните каталог tests или созданный подкаталог файлами, аналогичными тем, что находятся в каталоге native в примере изменения gerrit. В разделах ниже каждый файл будет подробно описан.

Исходный код

В качестве примера можно привести Hello World GTest .

Исходный код этого примера аннотирован здесь:

#include <gtest/gtest.h>

Заголовочный файл включается для GTest. Зависимость от включаемого файла автоматически разрешается с помощью BUILD_NATIVE_TEST в make-файле.

#include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}

Тесты пишутся с помощью макроса TEST : первый параметр — имя тестового случая, второй — имя теста. Вместе с именем исполняемого файла теста они образуют следующую иерархию на панели результатов:

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

Более подробную информацию о написании тестов с помощью GTest можно найти в документации GTest .

Простой файл конфигурации

Каждый новый тестовый модуль должен иметь файл конфигурации, управляющий системой сборки, включая метаданные модуля, зависимости компиляции и инструкции по упаковке. В большинстве случаев достаточно файла Blueprint на основе Soong. Подробнее см. в разделе «Простая конфигурация теста» .

Сложный конфигурационный файл

Чтобы вместо этого использовать Trade Federation, напишите тестовый файл конфигурации для тестового инструментария Android, Trade Federation .

Конфигурация теста может указывать специальные параметры настройки устройства и аргументы по умолчанию для предоставления тестового класса.

Сборка и тестирование локально

Для наиболее распространенных случаев использования используйте Atest .

Для более сложных случаев, требующих более серьезной настройки, следуйте инструкциям по использованию приборов .