Если вы новичок в разработке под 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. В разделах ниже будет более подробно объяснен каждый файл.
Исходный код
В качестве примера обратитесь к тесту GTest "Hello World" .
Исходный код этого примера приведен здесь:
#include <gtest/gtest.h>
Включаемый заголовочный файл для GTest. Зависимость от включаемого файла автоматически разрешается с помощью BUILD_NATIVE_TEST в файле makefile.
#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 .
В более сложных случаях, требующих более серьезной индивидуальной настройки, следуйте инструкциям по применению измерительного оборудования .