Хорошие практики написания кода для автотестов

Что проверяют

Отличаете ли вы автотест от скрипта, записанного рекордером. По ответу видно, чинили ли вы чужие тесты через полгода после написания, и понимаете ли, где проходит граница между стабильным набором и постоянным источником ложных падений.

Как отвечать

Начните со структуры, это главное для поддерживаемости:

• тест описывает сценарий словами предметной области, работа со страницей спрятана в отдельный слой вроде Page Object, запросы и данные ещё в один;
• локаторы устойчивые: отдельный атрибут для тестов, а не путь по вёрстке, который сломает первый же редизайн;
• ожидания явные, по состоянию элемента, вместо пауз фиксированной длины;
• тест сам готовит данные, быстрее всего через API, и сам за собой убирает; порядок запуска не должен влиять на результат;
• одна проверка отвечает на один вопрос, а сообщение о падении объясняет, что именно не совпало.

Добавьте про процесс: тесты проходят ревью наравне с продуктовым кодом, нестабильные уезжают в карантин с заведённой задачей, а проверки по возможности спускаются на уровень API и юнит-тестов, потому что через интерфейс всё медленно и хрупко.

Где спотыкаются

Ставят паузы фиксированной длины вместо ожидания состояния. Прогон разрастается до часов, а тесты всё равно мигают, потому что угаданной секунды иногда не хватает, а чаще она просто потрачена зря.

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

Проверяют не тот факт: что страница открылась или что ответ пришёл с кодом двести. Набор зелёный, а ошибка в расчёте суммы уезжает в прод, потому что никто не сравнил результат с ожидаемым значением.