РАЗРАБОТКА

Российский разработчик создал BitDive для поиска скрытых багов в микросервисах

BitDive анализирует HTTP-трафик между сервисами и находит регрессии, которые пропускают юнит-тесты и контрактные проверки. Решение для Java-команд.

✍️ Редакция iTech News | 03.03.2026 | ⏱ 2 мин | 👁 4 | Источник: DEV Community
📦

Все тесты зелёные, деплой прошёл успешно, а в продакшене внезапно ломаются downstream-сервисы. Знакомая ситуация для команд с микросервисной архитектурой — и именно её решает инструмент BitDive от российского разработчика Дмитрия Турмышева.

Самые опасные баги микросервисов находятся не внутри сервиса, а между ними. Изменение кода может сломать взаимодействие с другими API, но при этом все локальные тесты остаются зелёными.

Почему стандартные тесты не помогают

Классический сценарий: разработчик обновил Jackson или изменил DTO. Юнит-тесты проходят — они мокают HTTP-клиент. Интеграционные тесты тоже зелёные. Сервис уходит в прод, и через несколько часов downstream-сервис начинает выбрасывать ошибки десериализации.

Причина — сервис изменил формат данных на HTTP-уровне, но ни один тест это не проверял. Например, после обновления Jackson поле createdDate стало сериализоваться как Unix timestamp вместо строки, а status: "ACTIVE" превратился в status: 0.

Структурная проблема:

  • Юнит-тесты полностью мокают HTTP-клиент — не видят реальной сериализации
  • Контрактные тесты (Pact) проверяют заранее заданные примеры — если пример не покрывает конкретное поле, регрессия проскочит
  • OpenAPI валидация проверяет схему, но не поведение сериализации в рантайме
  • E2E тесты медленные и покрывают узкий набор сценариев

Как работает BitDive

BitDive захватывает execution traces из работающих Java-приложений. Каждый trace включает полную детализацию исходящих HTTP-вызовов: метод, URL, заголовки, тело запроса и ответа — именно в том виде, как они передаются по сети.

Ключевое отличие: это реальный runtime-обмен, а не Java-объект до сериализации. Если Jackson сериализует BigDecimal как "19.99" в базовой версии, но как 19.99 после изменения ObjectMapper — разница видна в trace.

Инструмент сравнивает traces до и после изменений кода и выявляет четыре типа регрессий:

  1. Изменение сериализации — формат даты, enum'ов, чисел
  2. Пропадание заголовков — например, Authorization после рефакторинга interceptor'а
  3. Изменение структуры payload'а — переименование или удаление полей
  4. Новые исключения — другой класс ошибки или стек трейс

Что это даёт командам

BitDive закрывает слепую зону между юнит-тестами и полноценным E2E тестированием. Особенно актуально для команд, которые активно обновляют зависимости — Spring Boot, Jackson, MapStruct — и сталкиваются с непредсказуемыми изменениями поведения в продакшене.

Инструмент пока работает только с Java, но концепция применима к любому языку с HTTP-взаимодействием между сервисами.

Поделиться: Telegram X LinkedIn