На этой странице описывается, как написать новый тестовый исполнитель в Tradefed.
Фон
Если вам интересно узнать место тестовых исполнителей в архитектуре Tradefed, см. раздел Структура тестового исполнителя .
Это не является обязательным условием для написания нового тестового исполнителя; тестовые исполнители могут быть написаны изолированно.
Минимум: реализовать интерфейс
Минимальным условием для квалификации в качестве исполнителя тестов Tradefed является реализация интерфейса IRemoteTest , а точнее метода run(TestInformation testInfo, ITestInvocationListener listener) .
Этот метод вызывается системой при использовании средства запуска тестов, аналогично Java Runnable.
Каждая часть этого метода считается частью выполнения тестового запуска.
Отчет о результатах от тестировщика
Метод run в базовом интерфейсе предоставляет доступ к объекту-слушателю типа ITestInvocationListener . Этот объект является ключом к передаче структурированных результатов от исполнителя тестов в систему.
Предоставляя структурированные результаты, организатор тестирования обладает следующими свойствами:
- Составьте полный список всех проведенных тестов, укажите их продолжительность, а также были ли они пройдены, провалены или получены другие результаты.
- Если применимо, сообщите показатели, связанные с тестами, например показатели времени установки.
- Подходит для большинства инструментов инфраструктуры, например, для отображения результатов и показателей и т. д.
- Обычно его проще отлаживать, поскольку имеется более детальная трассировка выполнения.
При этом предоставление структурированных результатов не является обязательным; разработчик теста может просто захотеть оценить состояние всего прогона как ПРОЙДЕНО или НЕ ПРОЙДЕНО, не предоставляя никаких подробностей о фактическом выполнении.
Следующие события могут быть вызваны прослушивателем для уведомления системы о текущем ходе выполнения:
- testRunStarted: уведомить о начале группы тестовых случаев, связанных между собой.
- testStarted: Уведомить о начале выполнения тестового случая.
- testFailed/testIgnored: Уведомить об изменении состояния текущего тестового случая. Тестовый случай без изменения состояния считается пройденным.
- testEnded: Уведомить об окончании тестового случая.
- testRunFailed: Уведомляет, что общий статус выполнения группы тестовых случаев — «неудача». Тестовый запуск может быть пройден или провален независимо от результатов тестовых случаев, в зависимости от того, чего ожидалось при выполнении. Например, исполняемый файл, выполняющий несколько тестовых случаев, может сообщить о прохождении всех тестовых случаев, но с кодом выхода (по любой причине: утечка файлов и т. д.).
- testRunEnded: Уведомить об окончании группы тестовых случаев.
Ответственность за поддержание и обеспечение правильного порядка обратных вызовов лежит на разработчике тестового запуска, например, обеспечение вызова testRunEnded в случае исключения с использованием предложения finally .
Обратные вызовы тестовых случаев ( testStarted , testEnded и т. д.) необязательны. Тестовый запуск может быть выполнен без тестовых случаев.
Вы можете заметить, что эта структура событий вдохновлена типичной структурой JUnit . Это сделано специально, чтобы приблизить всё к чему-то базовому, с чем разработчики обычно знакомы.
Отчеты журналов от тестировщика
Если вы пишете собственный тестовый класс или средство запуска Tradefed, вам нужно реализовать IRemoteTest и получить слушателя ITestInvocationListener через метод run() . Этот слушатель можно использовать для регистрации файлов следующим образом:
listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);
Тест с устройством
Приведенный выше минимальный интерфейс позволяет запускать очень простые тесты, которые изолированы и не требуют каких-либо особых ресурсов, например, модульные тесты Java.
Разработчикам тестов, которые хотят перейти к следующему этапу тестирования устройств, понадобятся следующие интерфейсы:
- IDeviceTest позволяет получить объект
ITestDevice, который представляет тестируемое устройство и предоставляет API для взаимодействия с ним. - IBuildReceiver позволяет тесту получить объект
IBuildInfo, созданный на этапе поставщика сборки, содержащий всю информацию и артефакты, относящиеся к настройке теста.
Тестировщики обычно заинтересованы в этих интерфейсах, чтобы получить артефакты, связанные с выполнением, например, дополнительные файлы, и получить тестируемое устройство, которое будет использоваться в качестве цели во время выполнения.
Тест с несколькими устройствами
Tradefed поддерживает запуск тестов на нескольких устройствах одновременно. Это полезно при тестировании компонентов, требующих внешнего взаимодействия, например, сопряжения телефона и часов.
Чтобы написать тестовый исполнитель, который может использовать несколько устройств, вам необходимо реализовать IMultiDeviceTest , который позволит получить карту ITestDevice для IBuildInfo , содержащую полный список представлений устройств и связанную с ними информацию о сборке.
Метод установки из интерфейса всегда будет вызываться до метода run , поэтому можно с уверенностью предположить, что структура будет доступна при вызове метода run .
Тесты осведомлены о своих настройках
Для правильной работы некоторым реализациям тестовых тестов может потребоваться информация об общей настройке, например, некоторые метаданные о вызове или о том, какой target_preparer запускался ранее и т. д.
Чтобы добиться этого, исполнитель тестов может получить доступ к объекту IConfiguration , частью которого он является и в котором он выполняется. Более подробную информацию см. в описании объекта конфигурации .
Для реализации тестового исполнителя вам потребуется реализовать IConfigurationReceiver для получения объекта IConfiguration .
Гибкий тестовый раннер
Исполнители тестов могут обеспечить гибкий способ запуска своих тестов, если у них есть детальный контроль над ними. Например, исполнитель тестов JUnit может индивидуально запускать каждый модульный тест.
Это позволяет более крупной системе и инфраструктуре использовать этот тонкий контроль, а пользователям частично запускать программу тестирования с помощью фильтрации .
Поддержка фильтрации описана в интерфейсе ITestFilterReceiver , который позволяет получать наборы фильтров include и exclude для тестов, которые должны или не должны запускаться.
Мы придерживаемся правила, что тест будет запущен, если он соответствует одному или нескольким фильтрам включения и не соответствует ни одному из фильтров исключения. Если фильтры включения не указаны, следует выполнить все тесты, пока они не соответствуют ни одному из фильтров исключения.