Как работали с автотестами
Что проверяют
Писали ли вы тесты сами и понимаете ли, почему их распределяют по уровням.
Как отвечать
Расскажите по уровням, инструментам и практикам.
Уровни и пропорции. Чем выше уровень, тем медленнее и хрупче тест. Поэтому основную массу проверок держат на уровне юнитов и API, а через интерфейс проверяют небольшое число ключевых сценариев. Сотня тестов интерфейса, дублирующих проверку валидации, это гарантированно медленный и нестабильный набор.
Инструменты. Что использовали: pytest или JUnit как каркас, библиотека HTTP-запросов для API, Playwright или Selenium для веба, Appium для мобильных, отчёты в Allure.
Практики, которые стоит назвать:
- страничные объекты или иная изоляция локаторов, чтобы правка вёрстки чинилась в одном месте;
- изоляция данных: каждый тест готовит своё состояние и не зависит от порядка запуска. Тесты, работающие на общих данных, начинают падать при параллельном прогоне;
- подготовка данных через API или базу, а не кликами по интерфейсу: быстрее и надёжнее;
- явные ожидания вместо пауз. Фиксированная задержка это одновременно и медленно, и ненадёжно;
- запуск в конвейере на каждый пул-реквест, а полный набор по расписанию.
Борьба с нестабильностью. Это главная тема в разговоре про автотесты. Нестабильный тест хуже отсутствующего: команда перестаёт читать красный отчёт. Причины обычно три: неявные ожидания, зависимость от общих данных, зависимость от порядка. Повторный запуск как лечение допустим только временно и с обязательным разбором причины.
Что автоматизировать. Повторяемое и стабильное: регрессия, проверки API, критичные сценарии. Что не стоит: разово выполняемое, области в активной переделке, исследовательское тестирование.
Где спотыкаются
Строят набор из одних тестов интерфейса.
Ставят фиксированные паузы вместо ожиданий.
Терпят нестабильные тесты и привыкают к красному отчёту.
Готовят данные через интерфейс, из-за чего тест падает по чужой причине.