Если бы мне давали по 100₽ за каждый проект, где тесты написаны через жопу, я был бы миллионером!

Погружаясь в автоматизацию в Я.Лавке, я ожидал худшего. Но был приятно удивлён!

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

Скажете, так не бывает? Бывает! Это результат стратегического подхода к написанию тестов.
Делюсь правилами которые мы обсуждали на нашем прямом эфире с Миленой ⬇️

---

📋 КОДЕКС ПО НАПИСАНИЮ ТЕСТ-КЕЙСОВ

1️⃣ Консистентность

Все кейсы по единой структуре:
Страница/Фича → Саб-фича → Что проверяем

Не думай каждый раз «а как назвать этот тест?». Открыл предыдущий — скопировал структуру. Profit!

2️⃣ Оптимальность важнее атомарности

Можно плодить сотни микротестов: «проверить кнопку», «проверить текст», «проверить иконку». Да, покрытие будет, но и скорость прогона вырастет в разы.

✅ Объединяем связанные проверки в один кейс
❌ Но если нужно вернуться к началу и повторить половину шагов — лучше разделить

3️⃣ Шаги = действия, результаты = проверки

В шагах только 5 действий: Открыть, Нажать, Проскроллить, Ввести, Обновить (то, что умеет Playwright)

В ожидаемом результате — никаких действий! Только то, что УЖЕ произошло.

❌ «Должна открыться форма»
✅ «Форма открыта»

4️⃣ Скриншоты — не для красоты

Один скриншот в ожидаемом результате — это то, что проверяем скринтестом. Остальное — контекст.

Чем меньше лишнего на скриншоте, тем меньше он флапает при изменении дизайна!

5️⃣ Предусловия — это база знаний

Указывай конфиги, эксперименты, адреса. Через полгода коллега (или ты сам в 3 часа ночи) скажет спасибо 🙏

---

🤖 КОДЕКС АВТОМАТИЗАТОРА

1️⃣ Структура — святое

Все тесты: describe → apps → test со вложенными шагами

Все действия и проверки в test.step() с понятными описаниями — для читаемых отчётов!

⚡ Первый шаг — ВСЕГДА открытие страницы. Без вариантов.

2️⃣ Моки — не зло, если делать правильно

Мокаем только то, что сложно воспроизвести или нестабильно (платежи, внешние API, редкие кейсы)

📁 Все моки в одной директории specs/data
♻️ Не плодим копии — переиспользуем существующие
🌐 Общие моки в packages/playwright/mocks — для других команд

3️⃣ Локаторы — только data-testid

Забудьте про xpath, классы и тексты!

app.getByTestId(['page', 'component', 'element'])
Повторяющиеся локаторы — в константы. Иначе при изменении одного атрибута придётся менять в 50 местах.

4️⃣ Скриншоты с умом

❌ Не скриншотим всю страницу!

Важна оптимальность: совсем мелкий делать не стоит — проверяй фичу в контексте страницы.

🎯 Используем offset для контекста
🙈 hide для нестабильных элементов (таймеры, анимации)
🎬 Один скриншот на фичу — не дублируем проверки

5️⃣ Точные проверки без воды

❌ Не проверяем захардкоженные тексты! Используем API или i18n ключи.

✅ Видимость: .toBeVisible()
✅ Исчезновение: .not.toBeAttached()

⚠️ Минимизируем или отказываемся от .waitForTimeout() — это зло, которое замедляет!

---

⚡ САМОЕ ВАЖНОЕ!

🔵 Отдаём на ревью ТОЛЬКО зелёные тесты - не беси коллег!
🔵 Валидируем все скриншоты перед ревью - не беси коллег!
🔵 Описываем изменения в тикете/PR - не беси коллег!
🔵 Синхронизируем тест-кейсы с автотестами - не беси коллег!
🔵 Исправляем свои флапающие тесты ! - не беси коллег!

---

🎯 ЧТО РЕАЛЬНО ДАЮТ КОДЕКСЫ?

✔️ Новички погружаются в разы быстрее
✔️ Минус необоснованная критика на Code Review (всегда можно сослаться на кодекс)
✔️ Флапающих тестов стало гораздо меньше
✔️ Тесты читаются как документация (можно показывать даже менеджерам!)

---

💡 От себя: Документируйте свои практики, не держите знания в головах. 30 минут на написание правил сэкономят сотни часов всей команде!

Сохраняй и внедряй в свои проекты!
Было полезно? Ставь ❤️