Кратко: каждый подход решает разные задачи и дополняет другие. Ниже — суть, сильные/слабые стороны и реальные сценарии, где метод наиболее эффективен.
1) Unit tests
- Что: тестирование отдельных функций/классов в изоляции (моки/стабы для внешних зависимостей).
- Сильные стороны: быстрые, детальные, хороши для регрессий, просты в диагностике причин падений.
- Слабые стороны: не ловят проблемы интеграции/конфигурации/параллелизма; могут быть чрезмерно связаны с реализацией.
- Когда использовать (реальные сценарии): валидация бизнес-логики (валидация входных данных, расчёты цен/налогов), чистые функции (парсеры, форматтеры), юнит-классы доступа к данным с моками.
- Практика: строят "пирамиду" тестов — много unit, меньше интеграционных, ещё меньше end-to-end ($\approx 70:20:10$).
2) Integration tests
- Что: тестируют взаимодействие между компонентами (БД, сервисы, сеть).
- Сильные стороны: выявляют ошибки конфигурации, контракта, сериализации, транзакций и порядок вызовов.
- Слабые стороны: медленнее, сложнее поддерживать, могут быть фликтирующими (внешние сервисы, тайминги).
- Когда использовать (реальные сценарии): транзакционные сценарии с БД (атомарность, откат), интеграция с внешними API (аутентификация, контракт ответов), очереди сообщений/миграции данных, end-to-end сценарии с несколькими сервисами.
- Практика: использовать тестовые контейнеры/интеграционные стенды и прогонять в CI перед релизом.
3) Property-based tests (напр. QuickCheck)
- Что: проверка общих свойств системы на множестве автоматически сгенерированных случайных входов.
- Сильные стороны: обнаруживают неожиданные граничные случаи и комбинации, хороши для алгоритмов и инвариантов; находят шаблонные классы багов быстрее, чем ручные примеры.
- Слабые стороны: нужно правильно формулировать свойства и генераторы; диагностика (шринкинг) важна, иногда сложна; не заменяют интеграционные/юнит-тесты полностью.
- Когда использовать (реальные сценарии): сериализация↔десериализация (round-trip), парсеры/лексеры, сортировки/множества (идемпотентность, инволюции), арифметические/комбинаторные инварианты, проверка бизнес-правил на случайных ансамблях данных.
- Практика: запускать $\sim 10^2÷10^4$ сгенерированных случаев для каждого свойства; использовать шринкинг для воспроизводимости.
4) Fuzzing
- Что: массовая генерация входов (часто мутациями) для обнаружения крашей, UB, утечек памяти и нарушений безопасности.
- Сильные стороны: сильный в нахождении критических уязвимостей и редких крашей в парсерах, форматах и сетевых интерфейсах; эффективен для нативного кода и бинарных интерфейсов.
- Слабые стороны: мало дает семантических гарантий, может генерировать бессмысленные входы, требует инфраструктуры (корпусы, инструменты, ASAN/MSAN), анализ фалов сложен.
- Когда использовать (реальные сценарии): парсеры файлов (PDF, JPEG, JSON/CBOR), сетевые сервисы/протоколы, бинарные форматы и десериализация, уязвимости памяти в C/C++; также полезен для fuzz-инпута CLI/интерфейсов.
- Практика: продолжительные прогонные сеансы ($\sim 10^6$ мутаций и более) и использование инструментов с покрытием (coverage-guided fuzzing).
Короткие рекомендации по сочетанию:
- Базовая линейка: много unit-тестов для логики + набор интеграционных тестов для контрактов + property-based tests для инвариантов алгоритмов + fuzzing для входов/парсеров/безопасности.
- Автоматизируйте: unit/properties в быстрых CI-рангах, интеграционные и фазы fuzzing/длительного тестирования на nightly/стендах.
Если нужно, могу привести примеры конкретных фреймворков и конфигураций для каждой стратегии.