Если вы только начинаете разрабатывать для платформы 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!");
}
Тесты GTest пишутся с использованием макроса 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.
Для более сложных случаев, требующих более глубокой настройки, следуйте инструкциям по реализации.