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