Тестовое отображение

Это краткое введение в Test Mapping и объяснение того, как легко начать настройку тестов в Android Open Source Project (AOSP).

Что такое тестовое отображение?

Тестовое сопоставление - это подход на основе Gerrit, который позволяет разработчикам создавать правила тестирования до и после отправки непосредственно в дереве исходных текстов Android и оставлять решения о ветвях и устройствах для тестирования самой тестовой инфраструктуре. Определения тестового сопоставления - это файлы JSON с именем TEST_MAPPING, которые можно поместить в любой исходный каталог.

Atest может использовать файлы TEST_MAPPING для запуска тестов предварительной отправки в связанных каталогах. С помощью Test Mapping вы можете добавить тот же набор тестов для предварительной отправки проверок с простым изменением внутри исходного дерева Android.

См. Эти примеры:

Добавьте тесты предварительной отправки в TEST_MAPPING для services.core

Добавьте тесты предварительной отправки в TEST_MAPPING для tools / dexter, используя импорт

Test Mapping полагается на Test Harness Торговой федерации (TF) для выполнения тестов и отчетов о результатах.

Определение тестовых групп

Тестовое отображение группирует тесты через тестовую группу . Имя тестовой группы может быть любой строкой. Например, предварительная отправка может быть для группы тестов, запускаемых при проверке изменений. А тесты postubmit можно использовать для проверки сборок после слияния изменений.

Правила сценария сборки пакета

Чтобы Test Harness Trade Federation мог запускать тестовые модули Test Mapping для данной сборки, в этих модулях должен быть установлен test_suite для Soong или LOCAL_COMPATIBILITY_SUITE, установленный для Make в один из этих двух наборов:

  • общие-тесты - тесты, не зависящие от особенностей устройства. Большинство тестов должны входить в набор общих тестов, поскольку они могут быть построены на целевом объекте test_suites, который включает двоичные файлы (для собственных тестов) для всех поддерживаемых ABI (32 против 64).
  • device-tests - тесты зависят от конкретных функций устройства, могут выполняться только на определенных целевых устройствах или могут быть построены только на определенных целевых устройствах. Это верно независимо от того, является ли тест собственным тестом или тестом JUnit.

Примеры:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Настройка тестов для запуска в комплекте тестов

Для запуска теста внутри набора тестов тест:

  • не должен иметь поставщика сборки.
  • должен очищаться после его завершения, например, удаляя все временные файлы, созданные во время теста.
  • изменить настройки системы на значение по умолчанию или исходное значение.

  • не должен предполагать, что устройство находится в определенном состоянии, например, готово к root. Для запуска большинства тестов не требуются права root. Если для теста требуется root, он должен указать это с помощью RootTargetPreparer, например:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Создание файлов тестового сопоставления

Для каталога, требующего тестового покрытия, просто добавьте файл TEST_MAPPING JSON, как в примере ниже. Эти правила гарантируют, что тесты будут выполняться в режиме предварительной проверки при касании любых файлов в этом каталоге или любом из его подкаталогов.

По примеру

Вот пример файла TEST_MAPPING (он в формате JSON, но с поддержкой комментариев):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side native test with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side native test.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Установка атрибутов

В приведенном выше примере presubmit и postsubmit - это имена каждой тестовой группы . См. Определение тестовых групп для получения дополнительной информации о тестовых группах.

Имя тестового модуля или имя теста интеграции Торговой федерации (путь к ресурсу тестового XML-файла, например, uiautomator / uiautomator-demo ) можно задать в значении атрибута name . Обратите внимание, что в поле имени нельзя использовать name класса или name метода тестирования. Чтобы сузить количество тестов, которые нужно запустить, вы можете использовать здесь такие параметры, как include-filter . См. ( Пример использования include-filter ).

Настройка теста хоста указывает, является ли тест тестом без устройств, выполняемым на хосте. Значение по умолчанию - false , то есть для запуска теста требуется устройство. Поддерживаемые типы тестов: HostGTest для собственных тестов и HostTest для тестов JUnit.

Атрибут file_patterns позволяет вам установить список строк регулярного выражения для сопоставления относительного пути любого файла исходного кода (относительно каталога, содержащего файл TEST_MAPPING). В приведенном выше примере тест CtsWindowManagerDeviceTestCases будет запускаться в режиме предварительной отправки только тогда, когда любой файл java начинается с Window или Activity, который существует в том же каталоге файла TEST_MAPPING или любого из его подкаталогов, изменяется. Обратные косые черты \ необходимо экранировать, поскольку они находятся в файле JSON.

Атрибут импорта позволяет включать тесты в других файлах TEST_MAPPING без копирования содержимого. Обратите внимание, что файлы TEST_MAPPING в родительских каталогах импортированного пути также будут включены. Тестовое отображение допускает вложенный импорт; это означает, что два файла TEST_MAPPING могут импортировать друг друга, а Test Mapping может правильно объединять включенные тесты.

Атрибут options содержит дополнительные параметры командной строки TradeFed.

Чтобы получить полный список доступных опций для данного теста, запустите:

tradefed.sh run commandAndExit [test_module] --help

См. Раздел Обработка опционов TradeFed для получения более подробной информации о том, как работают опционы.

Запуск тестов с Atest

Чтобы выполнить правила предварительного тестирования локально:

  1. Перейдите в каталог, содержащий файл TEST_MAPPING.
  2. Выполните команду:
atest

Все тесты предварительной отправки, настроенные в файлах TEST_MAPPING текущего каталога и его родительских каталогов, запускаются. Atest найдет и запустит два теста для предварительной отправки (A и B).

Это самый простой способ запустить тесты предварительной отправки в файлах TEST_MAPPING в текущем рабочем каталоге (CWD) и родительских каталогах. Atest найдет и использует файл TEST_MAPPING в CWD и во всех его родительских каталогах.

Структурирование исходного кода

В следующем примере показано, как можно настроить файлы TEST_MAPPING в исходном дереве.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Содержимое src/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Содержание src/project_1/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Содержание src/project_2/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Указание целевых каталогов

Вы можете указать целевой каталог для запуска тестов в файлах TEST_MAPPING в этом каталоге. Следующая команда запустит два теста (A, B).

atest --test-mapping src/project_1

Запуск правил тестирования сообщений

Вы также можете использовать эту команду для запуска правил тестирования postubmit, определенных в TEST_MAPPING в src_path (по умолчанию CWD) и его родительских каталогах:

atest [--test-mapping] [src_path]:postsubmit

Запуск только тестов, для которых не требуется устройство

Вы можете использовать параметр --host для Atest, чтобы запускать только тесты, настроенные для хоста, для которых не требуется устройство. Без этой опции Atest будет запускать оба теста: те, которые требуют устройства, и те, которые работают на хосте и не требуют устройства. Тесты будут проводиться в двух отдельных комплектах.

atest [--test-mapping] --host

Определение тестовых групп

Вы можете указать тестовые группы в команде Atest. Следующая команда запустит все тесты postubmit, связанные с файлами в каталоге src / project_1, который содержит только один тест (C).

Или вы можете использовать : all для запуска всех тестов независимо от группы. Следующая команда запускает четыре теста (A, B, C, X):

atest --test-mapping src/project_1:all

Включая подкаталоги

По умолчанию при запуске тестов в TEST_MAPPING с Atest будут выполняться только тесты с предварительной отправкой, настроенные в файле TEST_MAPPING в CWD (или в заданном каталоге) и его родительских каталогах. Если вы хотите запустить тесты во всех файлах TEST_MAPPING в подкаталогах, используйте параметр --include-subdir чтобы Atest также включил эти тесты.

atest --include-subdir

Без параметра --include --include-subdir Atest будет запускать только тест A. С параметром --include --include-subdir Atest запустит два теста (A, B).

Комментарий на уровне строки поддерживается

Вы можете добавить комментарий // формата строки, чтобы дополнить файл TEST_MAPPING описанием следующих параметров. ATest и торговая федерация предварительно обработают TEST_MAPPING до допустимого формата JSON без комментариев. Чтобы файл JSON был чистым и легким для чтения, поддерживается только комментарий // формата на уровне строки.

Пример:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}