Модульное тестирование (unit testing)
- Что: тесты маленьких изолированных единиц кода (функция/метод/класс).
- Зачем: быстрое обнаружение регрессий, документирование контракта функции, упрощение рефакторинга.
- Как: писать тесты без обращения к базе/сети — использовать заглушки/моки; следовать Arrange–Act–Assert; тесты должны быть быстрые и детерминированные.
- Когда применять: всегда при разработке логики; базовый слой автоматических тестов.
Интеграционное тестирование
- Что: тесты взаимодействия нескольких компонентов (модулей, БД, внешних сервисов).
- Зачем: проверить корректность интеграций, миграций схем, сериализации, контрактов между компонентами.
- Как: использовать тестовую БД/контейнеры (Docker), тестовые инстансы сервисов или сервисы-заглушки (контрактные моки); писать ограниченное число сценариев, покрывающих критические пути.
- Когда применять: после покрытия модулей unit-тестами, при изменениях в интерфейсах между компонентами и перед релизом.
Приёмочное тестирование (acceptance / end-to-end)
- Что: тесты, проверяющие требования и бизнес-ценность сверху вниз (пользовательские сценарии, UI, API).
- Зачем: убедиться, что система выполняет требования заказчика/пользователя; регрессии на уровне функциональности.
- Как: автоматизировать ключевые сценарии (Playwright/Cypress/Selenium) или проводить ручные тесты по чек-листу; использовать реальные окружения или максимально приближённые.
- Когда применять: перед релизом, для валидации требований, при демонстрации функционала стейкхолдерам.
TDD (Test-Driven Development)
- Что: цикл «написать тест — сделать тест проходящим — рефакторить» (red–green–refactor).
- Зачем: формулировать требования до кода, получать быстрые единичные проверки, улучшать дизайн и тестируемость кода.
- Как: писать минимальный failing unit-тест, реализовать минимальный код для прохождения, затем рефакторить; применять для сложной логики и ядра продукта.
- Когда применять: при разработке новой логики/фичи, при реализации библиотечных/критических модулей; в маленьком проекте часто оправдано для ключевых частей.
Как выстраивать процесс тестирования в небольшом учебном проекте
- Начните с критериев приёмки: опишите пары «scenario — expected result» (acceptance criteria).
- Применяйте TDD для ключевой бизнес-логики, чтобы получить чистый и протестированный код.
- Покройте логику unit-тестами: быстрые, локальные, выполняются при каждом коммите.
- Добавьте несколько интеграционных тестов для критичных интеграций (БД, API). Для простоты используйте контейнеры или in-memory БД.
- Автоматизируйте пару приёмочных сценариев (E2E) для главного пользовательского пути; остальные проверки — ручные.
- Настройте CI: при каждом PR запускать unit-тесты, на merge/ночной запускать интеграционные и E2E (пара медленных прогонов). Формула потока: $\text{unit}\to \text{integration}\to \text{acceptance}$.
- Практики: изолируйте тесты, держите их быстрыми, избегайте флейков, пишите понятные имена, поддерживайте тестовые данные и фикстуры.
- Метрики: следите за скоростью выполнения тестов и стабильностью; покрытие кода используйте как ориентир, но не цель (не гнаться за $100\%$).
Короткие рекомендации по приоритету в учебном проекте
- Сначала: несколько приёмочных сценариев + TDD для основной логики.
- Затем: широкие unit-тесты.
- Потом: ограниченные интеграционные тесты на ключевые точки.
- CI: минимум автоматический запуск unit-тестов при каждом коммите.
Если нужно — могу предложить пример структуры тестов и пример CI-конфигурации для конкретного стека (Python/JavaScript/Java).