Как сделать удобный инструмент для тестирования операционной системы

Спикер расскажет, как в его команде написали обвязку для PyTest и теперь прогоняют разные типы тестов для разных продуктов — от разных команд на разном железе в требованиях SDL.

В каждой компании, выпускающей релизы крупных продуктов, возникает потребность в согласованной работе нескольких подразделений, отвечающих за разные области ответственности в процессе создания продукта:

• Разработчики хотят писать код и юнит-тесты для своих модулей, иметь при этом понятный и максимально прозрачный интерфейс взаимодействия с тестовой инфраструктурой, а также иметь возможность одной командой запустить тесты своего кода на любом доступном железе.
• Тестировщики хотят легко и непринужденно писать автотесты, имея при этом понятную и удобную абстракцию от компонентов и сервисов тестовых стендов, а также простой способ собирать и расширять стендовую базу. И писать они хотят на Python, поскольку он предоставляет большое количество готовых библиотек на все случаи жизни.
• Билд-инженеры хотят иметь стабильные, не флакающие конвейеры и легко встраиваемую в них утилиту для тестирования и сбора метрик.
• Менеджеры хотят иметь статистику по багам, метрикам производительности на разных релиз-кандидатах для разных целевых платформ, а также тестовые планы, успешное выполнение которых является однозначным критерием качества выпускаемого релиза. 

Чтобы угодить всем им, требуется написать много разнородного кода. В команде спикера попробовали структурировать его и на основе PyTest в качестве движка написали инструмент, удовлетворяющий желаниям всех перечисленных ролей. Главной идеей была модульность, которая дает возможность из набора готовых кубиков собирать любые конфигурации. 

В докладе пойдет речь о проблемах, стоявших перед командой, о том каким образом эти проблемы удалось решить, какой инструмент в итоге получился, и как стали выглядеть тесты, использующие этот инструмент.