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