Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

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

Если вы новичок в разработке платформы Android, вам может показаться, что этот полный пример добавления совершенно нового собственного теста с нуля полезен для демонстрации типичного рабочего процесса. Кроме того, если вы также не знакомы с платформой gtest для C ++, просмотрите сайт проекта gtest для получения дополнительной документации.

В этом руководстве в качестве образца используется следующий тест:

Hello World Native Test

Рекомендуется сначала просмотреть код, чтобы получить грубое впечатление, прежде чем продолжить.

Выбор исходного местоположения

Обычно ваша команда уже имеет установленный шаблон мест для проверки кода и мест для добавления тестов. Большинству команд принадлежит один репозиторий 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 каталог tests или только что созданный вложенный каталог файлами, похожими на те, которые находятся в native каталоге в примере изменения Gerrit. Разделы ниже объяснят более подробно каждый файл.

Исходный код

Посмотрите Hello World Native Test для примера.

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

 #include <gtest/gtest.h>
 

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

 #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. См. Простая конфигурация теста для деталей.

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

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

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

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

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

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