Google is committed to advancing racial equity for Black communities. See how.
Эта страница переведена с помощью Cloud Translation API.
Switch to English

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

Если вы новичок в разработке платформы 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 каталог tests или вновь созданный подкаталог файлами, подобными тому, что находится в native каталоге в примере изменения gerrit. В разделах ниже приводится более подробная информация о каждом файле.

Исходный код

См. Пример в тесте Hello World Native .

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

#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 .

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