Браузерное E2E-тестирование frontend
Выбрать пользовательский путь
Определи действие пользователя, видимый критерий завершения и границу, для которой нужен браузер. Арифметику, исчерпывающие комбинации валидации и большую часть ветвлений оставляй на нижних уровнях тестирования. Выбирай несколько характерных сквозных путей вместо воспроизведения каждого модульного случая через UI.
Сделать тест различающим поведение
- Используй семантические роли элементов и их доступные имена либо намеренно созданные устойчивые тестовые идентификаторы, подходящие интерфейсу. Избегай селекторов, смысл которых сводится к текущему положению в DOM или оформлению; повторяющиеся элементы ищи в пределах нужного компонента.
- С ограниченным таймаутом ожидай условие, от которого зависит действие пользователя. Произвольная пауза не доказывает готовность, а фоновая сетевая активность может не иметь отношения к завершению действия.
- Изолируй и браузерное состояние, и серверные тестовые данные. Новый браузер не изолирует два теста, меняющих одну учётную запись или ресурс. Подготавливай собственные записи, при необходимости используй независимые учётные записи или пространства имён и удаляй только состояние, принадлежащее тесту.
- Проверяй навигацию, перезагрузку, валидацию и восстановление, если они входят в изменяемый путь. Для воспроизведения ошибки устаревшего ответа управляй порядком ответов, а не надейся на обычные задержки.
- Для изменённых элементов управления включай относящиеся к задаче действия с клавиатуры, имена для средств доступности и поведение фокуса. Один визуальный снимок или автоматический сканер доступности не подтверждает все доступные взаимодействия.
- При изменении макета проверяй характерные границы размеров экрана и содержимого. Скриншоты должны показывать полезное состояние, а не заменять проверки сохранения данных или успешного действия изображением страницы.
Подменяй зависимость, когда это нужно для воспроизводимой подготовки или ошибочного ответа, но указывай, какая интеграция при этом исключается из проверки. Не называй сквозной проверкой полностью изолированный компонентный тест с заглушками.
Выполнить и сообщить результат
Используй существующий браузерный framework репозитория и интерфейсы, поддерживаемые его версией. Запускай тесты в предоставленном окружении в пределах его разрешений; не переноси побочные эффекты в реальные учётные записи или внешние сервисы ради работоспособности тестовых данных.
Классифицируй нестабильный сбой по доказательствам: гонка продукта, утечка состояния между тестами, неустойчивый селектор или сбой окружения. Повторы до зелёного результата не являются исправлением, а отключение теста без дальнейшей работы скрывает сигнал регрессии.
Верни прицельные тесты, требования к подготовке, наблюдаемые результаты и полезные материалы о сбоях с тестовыми данными. Явно обозначь невыполненные браузерные проверки, проверки макета и доступности; отдельный документ передачи работы не нужен для небольшого изменения теста.