Post #44

🔥 Всем привет! Сегодня поговорим про E2E-тесты и почему для меня это самые нелюбимые тесты 🤯 🧪 Что такое E2E? E2E — это тесты, которые проверяют всю цепочку работы системы, как будто это делает реальный пользователь. Даже если у нас 100% покрытие юнит-тестами — без E2E тяжело выпускать фичи с уверенностью. 🛠️ Я говорю про E2E, которые запускаются в CI в отдельном окружении. 🚧 В чём проблема? E2E-тесты проверяют весь сценарий: - запросы в базу, - вызовы смежных сервисов, - реальное поведение системы. 📦 С базой — всё ок, можно поднять тестовые миграции. 😵‍💫 А вот со смежными сервисами — начинаются проблемы, особенно если они: - многочисленные, - связаны между собой 🛤️ Подходы ✅ Вариант 1: Поднять все сервисы Плюсы: - полное соответствие прод-окружению. Минусы: 💸 дорого по ресурсам; 🧩 сложно отлаживать: непонятно, где именно упало; 🐌 долго. 🧪 Вариант 2: Мокать вызовы Плюсы: - быстрый запуск; - понятно, где баг; - легко тестировать пограничные случаи. Минусы: 🤖 моки быстро устаревают; ⚙️ сложные моки (например, с логикой по входным данным). Мой выбор Я чаще выбираю второй подход — он стабильнее и проще в CI. Использую 🔧Mockoon — можно: - настроить моки в UI, - поднять Docker-контейнер с CLI версией, - поднимать рядом с тестами и делать запросы по HTTP. 😩 Почему я не люблю E2E? Потому что, чтобы протестировать одну фичу, иногда приходится: - мокать десятки ответов; - тратить на это больше времени, чем на саму разработку 😬 💬 А как вы подходите к E2E? Поделитесь в комментах — всегда интересно посмотреть на другие подходы 👇