Тестовое сопоставление

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

О тестовом сопоставлении

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

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

Посмотрите эти примеры:

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

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

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

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

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

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

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

• General-tests — тесты, которые не зависят от функциональности конкретного устройства (например, аппаратного обеспечения конкретного производителя, которого нет у большинства устройств). Большинство тестов должны входить в набор общих тестов, даже если они относятся к одному ABI, разрядности или аппаратным функциям, таким как HWASan (для каждого ABI существует отдельная цель test_suites), и даже если их приходится запускать на устройстве.
• device-tests — тесты, зависящие от функциональности конкретного устройства. Обычно эти тесты находятся в vendor/ . Поскольку термин «зависит от устройства» не относится к функциям ABI или SoC, которые могут или не могут быть у других устройств, а только к функциям, уникальным для устройства , это применимо к тестам JUnit в такой же степени, как и к собственным тестам GTest (которые обычно должны быть general-tests даже если они специфичны для ABI).

Примеры:

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

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

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

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

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

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

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

Следуйте примеру

Вот пример файла 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 GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Установить атрибуты

В приведенном выше примере presubmit и postsubmit — это имена каждой тестовой группы . Дополнительную информацию о группах тестов см. в разделе Определение групп тестов.

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

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

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

Атрибут imports позволяет включать тесты в другие файлы 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

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

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

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

Запускайте только тесты, не требующие устройства

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

atest [--test-mapping] --host

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

Вы можете указать группы тестов в команде Atest. Следующая команда запустит все тесты после отправки , связанные с файлами в каталоге 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-subdir Atest запустит только тест A. С опцией --include-subdir Atest запустит два теста (A, B).

Поддерживаются комментарии на уровне строки.

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

Пример:

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