Урок 2. Почему UI-тестов должно быть меньше
Пирамида автотестов
Темы урока
Пирамида тестирования (unit/API/UI), почему E2E-тестов должно быть меньше всего, smoke и regression, Selenium vs Cypress vs Playwright, что реально автоматизируют в компаниях
Видео урока
Конспект урока
Конспект — Урок 2: Почему UI-тестов должно быть меньше
Главное за урок
Пирамида тестирования — не мода, а экономика. Unit-тестов много: они быстрые и дешёвые. API — меньше. UI/E2E — меньше всего: они медленные, хрупкие и дорогие в поддержке. Если перевернуть пирамиду (почти все проверки через браузер), регресс будет краснеть от любой анимации.
На эфире это разбирали на PomidorQA: один и тот же сценарий бронирования можно проверить на трёх уровнях — и цена ошибки разная.
Три уровня пирамиды
| Уровень | Что проверяет | Пример на PomidorQA | Скорость |
|---|---|---|---|
| Unit | Функция / правило без браузера и сети | Слот нельзя забронировать дважды — чистая логика | Миллисекунды |
| API | Контракт сервера, статусы, данные | Бронь слота через серверную логику / мок API | Секунды |
| UI / E2E | Реальный путь пользователя в браузере | Регистрация → каталог → клик по слоту → модалка | Десятки секунд |
Почему E2E меньше всего: каждый клик зависит от вёрстки, сети, анимаций, данных на общем стенде. Один редизайн кнопки валит пачку тестов. Unit и API ловят ту же бизнес-ошибку дешевле.
Smoke и regression
| Прогон | Зачем | Что входит |
|---|---|---|
| Smoke | «Система жива» после деплоя | Короткий критичный путь: логин, открыть каталог, создать сущность |
| Regression | Ничего старого не сломали | Шире: позитив + ключевой негатив по уже стабильным фичам |
Smoke гоняют часто и быстро. Regression — перед релизом или по расписанию. Путать их нельзя: если «смоук» длится час, это уже не смоук.
Инструменты: Selenium, Cypress, Playwright
| Selenium | Cypress | Playwright | |
|---|---|---|---|
| Возраст / модель | Классика, WebDriver | Свой раннер, один браузер в фокусе | Современный, несколько браузеров из коробки |
| Языки | Много | В основном JS/TS | JS/TS, Python, Java, .NET |
| Auto-waiting | Слабее, часто свои wait | Есть | Сильный из коробки |
| Контексты / несколько пользователей | Через отдельные драйверы | Исторически больнее | browser.newContext() — штатно |
Курс на Playwright + TypeScript: auto-waiting, удобные локаторы, изоляция пользователей через контексты — это прямо нужно PomidorQA (хост и гость в одном тесте).
Что автоматизируют в компаниях — и что почти никогда
Автоматизируют: критичный пользовательский путь, стабильные формы, регресс перед релизом, проверки, которые иначе гоняют руками каждую неделю.
Почти никогда: визуал «красиво ли», разовые админские сценарии, сырой UI, капча, всё, что живёт один спринт.
Правило с Урока 1 здесь же: важность + частота повторения. Если сценарий редкий и дорогой в поддержке — оставь его ручным.
Ключевые тезисы для теста
- Пирамида: много unit, меньше API, ещё меньше UI/E2E.
- E2E дороже и хрупче — поэтому их должно быть меньше, а не «покрыть всё кликами».
- Smoke — короткий «жив ли стенд»; regression — широкий прогон стабильного функционала.
- Playwright выбран из‑за auto-waiting, локаторов и
newContextдля нескольких пользователей. - Не всё стоит автоматизировать: одноразовое, сырое и чисто визуальное — обычно нет.
Полезные ссылки
- Test Pyramid (Martin Fowler): https://martinfowler.com/bliki/TestPyramid.html
- Playwright — Why Playwright: https://playwright.dev/docs/why-playwright
- Стенд PomidorQA: https://aiqa.su/pomidorqa
- Репозиторий курса: https://github.com/lebed52/pomidorqa-course-tests
- Чат марафона: https://t.me/+NJgJrdqfLLozMTY6
Домашнее задание
Индивидуальная проверка ДЗ — на Boosty
Конспект, видео и тест открыты всем. Текст задания и проверка работы — по подписке.
Индивидуальная проверка ДЗ на Boosty