На этой странице описывается, как написать новый тестовый исполнитель в 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 или runner, вы реализуете 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 для тестов, которые должны или не должны запускаться.
Наше соглашение заключается в том, что тест будет запущен, ЕСЛИ он соответствует одному или нескольким фильтрам включения И не соответствует ни одному из фильтров исключения. Если не указаны фильтры включения, все тесты должны быть запущены, пока они не соответствуют ни одному из фильтров исключения.