Зачем и что тестировать
Автотест, Arrange-Act-Assert, виды тестов и что стоит тестировать.
Обновлено
Что такое автотест
Автоматический тест — это код, который запускает другой код и проверяет, что тот делает то, что должен. Вместо того чтобы после каждого изменения открывать браузер и кликать вручную, вы запускаете команду и за секунды узнаёте, не сломали ли что-то.
test('применяет скидку 10%', () => {
expect(applyDiscount(100, 'WELCOME10')).toBe(90)
})Ровно то, что делают упражнения в этом приложении: ваш код + несколько проверок.
Почему это стоит того
- Уверенность при изменениях — рефакторите без страха; тесты скажут, если что-то сломалось.
- Баги ловятся рано — в CI, а не пользователями.
- Документация — тесты показывают, как использовать код.
- Лучший дизайн — код, который трудно тестировать, обычно слишком связан.
Анатомия теста: Arrange – Act – Assert
test('добавляет товар в корзину', () => {
const cart = createCart() // Arrange — готовите данные
cart.add({ id: 1, price: 50 }) // Act — запускаете проверяемый код
expect(cart.total).toBe(50) // Assert — проверяете результат
})Виды тестов
| Вид | Проверяет | Скорость | Уверенность | Инструменты |
|---|---|---|---|---|
| статические | типы, синтаксические ошибки, стиль | мгновенно | базовая | TypeScript, ESLint |
| unit | одну функцию / модуль изолированно | мс | для логики | Vitest |
| интеграционные | несколько частей вместе (компонент + хук + данные) | быстро | высокая | Vitest + Testing Library |
| end-to-end (E2E) | настоящее приложение в настоящем браузере, как пользователь | секунды | максимальная | Playwright |
Пирамида или «кубок»
Классика: пирамида — много unit-тестов, меньше интеграционных, немного E2E.
Для фронтенда современная рекомендация (Кент С. Доддс) — «testing trophy»: статическая база (TS + ESLint), больше всего интеграционных тестов, немного unit для сложной логики и немного E2E для критичных сценариев (вход, оформление заказа).
Причина: интеграционный тест больше похож на то, как пользователь работает с приложением → даёт больше уверенности на каждый написанный тест.
Что стоит тестировать
| Высокий приоритет | Низкий приоритет |
|---|---|
| бизнес-логика (цены, скидки, валидация) | детали стиля, цвета |
| критичные сценарии (вход, оплата, сохранение) | код фреймворка (Next сам тестирует свой роутинг) |
| исправленные баги (тест, чтобы не вернулись) | тривиальные геттеры / сеттеры |
| утилиты, используемые повсюду | внутренняя реализация, которая часто меняется |
Тестируйте поведение, а не реализацию. Хороший тест не ломается, когда вы переименовываете внутреннюю переменную, — только когда меняется видимое поведение.
Коротко
- Тест = код, проверяющий другой код; Arrange → Act → Assert.
- Статические, unit, интеграционные, E2E — у каждого своя цена и уверенность.
- Тестируйте поведение; в приоритете бизнес-логика и критичные сценарии.