Добавление нового примера собственного теста

Если вы новичок в разработке платформы Android, этот полный пример добавления нового нативного теста с нуля может оказаться полезным для демонстрации типичного рабочего процесса. Кроме того, если вы также знакомы с GTEST рамки для C ++, пожалуйста , просмотрите 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 каталоге в образце изменения Геррита. В разделах ниже приводится более подробная информация о каждом файле.

Исходный код

См Hello World Test Native для примера.

Аннотированный исходный код приведен ниже:

#include <gtest/gtest.h>

Заголовочный файл для gtest. Обратите внимание , что включают в себя зависимость файла автоматически решена с помощью BUILD_NATIVE_TEST в Makefile

#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 см. Его документацию:

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

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

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

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

Для использования Торговой Федерации вместо записи в файл конфигурации тестирования для тестового жгуте Андроида, Торговой Федерации .

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

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

При большинстве случаев общего пользования, нанимают Atest .

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