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

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

На каждом проекте, если там уже были написаны хоть какие-то автотесты, я писал всё заново. Просто потому, что либо это были максимально простейшие реализации, мало чем отличающиеся от того, что нарисует Selenium IDE через прокликивание, либо переусложненные конструкции, в которых трудно разбираться и ещё сложнее масштабировать.

И честно не понимаю, почему. Есть несколько принципов, которые можно приложить к большинству проектов:

1. Page Object Model — базовый паттерн. И не надо накручивать по 5–6 уровней абстракции, их там всего три: базовые методы, объекты страницы или эндпоинты в случае API, и сами тесты. Всё! Для разбиения API эндпоинтов можно глянуть, как бэкендеры ведут Swagger. Им же проще будет понять структуру ваших тестов. Вот хороший материал про POM: Большой гайд по Page Object Model

2. Понятный нейминг, чтобы не засирать код комментариями на каждый чих.

3. Интеграция с TMS. Чтобы разбивать автотесты на понятные шаги. Это делает код читабельнее и упрощает понимание, где именно произошло падение автотестов. Особенно актуально, когда вы работаете вместе с мануальными тестировщиками. Пользуйтесь декораторами, и вам не придется комментировать код.

4. Логирование. Не надо надеяться только на отчеты в TMS или на Datadog и т.д. В первом случае они будут неполными, во втором искать долго. Playwright и аналоги представляют свои решения из коробки. Если же речь идет об автоматизации API, напишите простой логгер, который будет генерировать отчет в артефакты пайплайна. Это ускорит поиск причин падения тестов.

5. Используйте подходящий под ваши задачи стек. Не надо писать автотесты на API, используя Cypress или иные фреймворки автоматизации веба, если не собираетесь в перспективе автоматизировать этот самый веб. Адское переусложнение, которое тащит за собой тонны зависимостей, которые вам не нужны.

6. Следите за обновлениями. Нет ничего хуже, чем дождаться момента, когда какой-нибудь плагин перестанет работать и потребует обновления, а там вообще другой синтаксис и нужно всё срочно переписывать.

7. Сразу закладывайте вероятность масштабирования автотестов. То, что сегодня вам сказали, будто автотесты нужны только на stage, вообще не значит, что завтра они не понадобятся на dev или prod.

Резюме:

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

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