Пирамида тестирования мужчины
Все знают классическую пирамиду тестирования, но, как показывает практика, она не всегда спасает от багов.
End-to-End Tests
▲
│
Integration Tests
▲
│
Unit Tests
Реальный мир сложнее, и если хочешь спать спокойно, лучше добавить ещё несколько уровней.
Дополняем пирамиду тестирования
✅ Контрактные тесты
Любая интеграция — это источник боли, если не тестировать контракты. Будь то API (Swagger, OpenAPI), события в Kafka (Avro, Apicurio) или даже схемы в MongoDB — если контракт нарушен, тебя ждёт продакшн-ад.
✅ Тесты на кодстайл
Линтеры — это не просто про пробелы и запятые. Они помогают держать код в едином стиле и предотвращать базовые ошибки ещё до того, как ты задумаешься о логике.
✅ Архитектурные тесты
Если ты не хочешь, чтобы через полгода твой проект выглядел как Франкенштейн, стоит следить за архитектурой. В JVM-мире, например, есть ArchUnit, который позволяет чётко задать границы между слоями и контролировать зависимости.
Когда писать тесты?
Есть мнение, что тесты нужны только там, где появляется бизнес-логика, а вначале можно забить. Я категорически не согласен.
Чаще всего на старте проект в руках 2-3 человек, и чем больше автоматических проверок, тем выше качество на выходе. Меньше ручного тестирования — быстрее фичи в прод.
🔥 Отдельно хочу автоматизировать проверку уязвимостей, но вот всё руки не доходят… Но когда-нибудь я до этого доберусь. 😏
👉 А какие уровни тестирования добавляешь ты? Может, есть любимые инструменты, которые помогают не ловить баги на проде? Делись в комментах! 🚀
Код, баги, мемы и реальный опыт в IT.
Без воды, зато с пользой.
👉 Подписывайся: https://t.me/debug_leg