Добавление новых тестов Google (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!");
}

GTests пишутся с помощью макроса 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 .

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