Пирамида тестирования
↑ 2.2 Тестирование: основы · → Следующая
Зачем это на собесе
Что и как вы тестируете на фронтенде и в каком соотношении.
Объяснение
| Уровень | Что проверяет | Инструменты | Скорость |
|---|---|---|---|
| Статический анализ | типы, стиль, ошибки | TypeScript, ESLint, Prettier | мгновенно |
| Unit | функции, composables, сторы | Vitest, Jest | миллисекунды |
| Component | компонент с рендером и взаимодействием | Vue Test Utils, Testing Library | десятки мс |
| Integration | несколько модулей (страница + сторы + моки API) | Vitest + MSW | сотни мс |
| E2E | пользовательские сценарии в браузере | Playwright, Cypress | секунды |
| Визуальные | регрессия внешнего вида | Storybook + Chromatic, Playwright screenshots | секунды |
| Нефункциональные | a11y, производительность | axe, Lighthouse CI | по расписанию |
Пирамида: много быстрых unit-тестов, меньше компонентных/интеграционных, мало E2E. Для UI-приложений популярна «трофейная» модель (Testing Trophy): упор на интеграционные тесты с позиции пользователя, плюс статический анализ в основании.
Принципы:
- Тестируйте поведение, а не реализацию: что видит пользователь, а не внутренние переменные.
- Тест должен падать по одной причине и указывать на неё.
- Изолируйте внешний мир (сеть, время, случайность).
- Покрытие — индикатор, а не цель.
- Тесты должны быть быстрыми и стабильными (без flaky).
Нюансы и подводные камни
- Тестирование деталей реализации (приватные методы, структура DOM) ломается при рефакторинге.
- Слишком много E2E — медленно и нестабильно.
- Моки везде превращают тест в проверку моков.
- Снимки (snapshots) больших компонентов быстро принимают «на веру».
Практика
- Распределите существующие тесты по уровням и найдите пробелы.
- Определите, что в вашем приложении критично покрыть E2E (3–5 сценариев).
- Настройте запуск unit-тестов в pre-commit/CI.
Вопросы с ответами
Что такое пирамида тестирования?
Модель распределения тестов: больше быстрых unit-тестов внизу, меньше интеграционных, минимум E2E наверху.
Что тестировать на фронтенде в первую очередь?
Бизнес-логику (функции, composables, сторы), критичные пользовательские сценарии и границы с API.