Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу про контрактное тестирование на Kotlin — подход, который экономит десятки часов отладки и спасает от неожиданных падений продакшена.
Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, много лет проектирую и сопровождаю микросервисы в высоконагруженных системах. Преподаю на курсах разработки и архитектуры в OTUS, и регулярно вижу, как даже опытные команды спотыкаются на интеграционном тестировании. Вроде бы всё покрыто автотестами, CI зелёный, а после деплоя пользователи сыплют баг-репортами: «Приходит пустой список заказов», «Поле customerId вдруг стало null». Знакомая картина?
Сегодня разберём, как контрактные тесты решают эту проблему. Создадим потребительский контракт на Kotlin с помощью Pact, проверим, что бэкенд ему соответствует, и обсудим типичные ошибки, из-за которых тесты превращаются в фикцию. А в конце поделюсь, где можно глубже прокачать навыки автоматизации тестирования на Kotlin, чтобы не наступать на эти грабли в своих проектах.
Почему интеграционные тесты не спасают
Интеграционные тесты проверяют, как сервисы общаются здесь и сейчас. Они хороши, когда у вас есть полная копия продакшен-окружения. Но стоит одному из сервисов изменить API — и ваши тесты всё ещё зелёные, потому что запускаются на старой версии. А в продакшене получаем сюрприз :((
Контрактное тестирование переворачивает логику. Вместо того чтобы проверять «работает ли интеграция в текущий момент», мы фиксируем ожидания потребителя от провайдера. Провайдер гарантирует, что не сломает эти ожидания в будущем. При этом каждая сторона тестирует только себя, что даёт быструю обратную связь прямо на этапе сборки.
Если говорить совсем просто:
Интеграционный тест спрашивает: «Могут ли сервис A и сервис B договориться прямо сейчас?»
Контрактный тест спрашивает: «Выполняет ли сервис B обещания, данные сервису A?»
Pact на Kotlin: с чего начать?
Среди инструментов для контрактного тестирования в JVM-мире де-факто стандартом стал Pact. Он позволяет описать контракт в виде JSON-файла, который генерируется на стороне потребителя, а затем верифицируется у провайдера. Для Kotlin есть удобная обёртка pact-jvm-consumer-kotlin с DSL, который выглядит почти как родной код.
Давайте сразу к практике. Представьте: у нас есть мобильное приложение (потребитель) и бэкенд-сервис user-service (провайдер). Приложение ожидает, что эндпоинт GET /users/{id} вернёт JSON определённой структуры.
Шаг 1. Пишем контракт на стороне потребителя
Создаём тест, который описывает ожидания от API:
import au.com.dius.pact.consumer.dsl.PactDslJsonBody import au.com.dius.pact.consumer.dsl.PactDslWithProvider import au.com.dius.pact.consumer.junit5.PactConsumerTestExt import au.com.dius.pact.consumer.junit5.PactTestFor import au.com.dius.pact.core.model.RequestResponsePact import au.com.dius.pact.core.model.annotations.Pact import org.junit.jupiter.api.Test import org.junit.jupiter.api.extension.ExtendWith import org.springframework.web.client.RestTemplate @ExtendWith(PactConsumerTestExt::class) @PactTestFor(providerName = "user-service", port = "8080") class UserServiceConsumerPactTest { @Pact(consumer = "mobile-app") fun getUserById(builder: PactDslWithProvider): RequestResponsePact { return builder .given("user with id 123 exists") .uponReceiving("a request for user 123") .path("/users/123") .method("GET") .willRespondWith() .status(200) .body( PactDslJsonBody() .integerType("id", 123) .stringType("name", "Alex") .stringType("email", "alex@example.com") .booleanType("active", true) ) .toPact() } @Test @PactTestFor(pactMethod = "getUserById") fun `should fetch user correctly`(mockServer: MockServer) { val response = RestTemplate().getForEntity("${mockServer.getUrl()}/users/123", String::class.java) assert(response.statusCode.is2xxSuccessful) // Здесь можно проверить маппинг в DTO } }
Обратите внимание: мы не поднимаем реальный user-service. Мы поднимаем мок-сервер, который Pact генерирует из нашего контракта!
Тест проверяет, что наш клиентский код корректно обрабатывает ожидаемый ответ. После прогона теста в выходной директории (например, target/pacts для Maven или build/pacts для Gradle) появляется JSON-файл контракта.
Шаг 2. Верификация контракта на стороне провайдера
Теперь мы должны убедиться, что бэкенд действительно отдаёт то, что обещано. Для этого на стороне провайдера пишем тест верификации:
import au.com.dius.pact.provider.junit5.HttpTestTarget import au.com.dius.pact.provider.junit5.PactVerificationContext import au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider import au.com.dius.pact.provider.junitsupport.Provider import au.com.dius.pact.provider.junitsupport.State import au.com.dius.pact.provider.junitsupport.loader.PactBroker import org.junit.jupiter.api.BeforeEach import org.junit.jupiter.api.TestTemplate import org.junit.jupiter.api.extension.ExtendWith import org.springframework.boot.test.context.SpringBootTest import org.springframework.boot.test.web.server.LocalServerPort @Provider("user-service") @PactBroker(host = "localhost", port = "9292") // если используется Pact Broker @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) class UserServiceProviderPactTest { @LocalServerPort var port: Int = 0 @BeforeEach fun setup(context: PactVerificationContext) { context.target = HttpTestTarget("localhost", port) } @TestTemplate @ExtendWith(PactVerificationInvocationContextProvider::class) fun verifyPacts(context: PactVerificationContext) { context.verifyInteraction() } @State("user with id 123 exists") fun `prepare user 123`() { // здесь подготавливаем данные в БД, например через Testcontainers } }
Этот тест поднимает реальный Spring Boot контекст (или его часть) и прогоняет запросы, описанные в контракте. Если реальный ответ отличается от ожидаемого, тест падает с чётким diff-ом.
Вот как выглядит процесс в целом (рис. 1):
Где чаще всего ошибаются и как этого избежать?
За время работы с Pact я выделил для себя основные ошибки. Вот главные.
1. Слишком жёсткий контракт.
Новички часто проверяют каждое поле, включая служебные (например, timestamp с точностью до миллисекунд). При каждом деплое провайдера контракт ломается, команда устаёт чинить тесты и отключает их. Правильно — проверять только то, что реально нужно потребителю. Используйте eachLike, minArrayLike и другие гибкие матчеры.
2. Забывают про состояния провайдера.
Контракт начинается с given("user with id 123 exists"). Если на стороне провайдера не реализован метод с аннотацией @State, верификация упадёт с загадочной ошибкой 404. Обязательно готовьте данные в соответствующих методах.
3. Тестируют только happy path.
Потребитель должен описать не только успешный ответ, но и сценарии ошибок: 404, 400, 500. Без этого провайдер может втихую изменить формат ошибки, и клиентское приложение не сможет его распарсить.
4. Публикуют контракты в общую папку без версионирования.
Рано или поздно вы поддержите несколько версий потребителей одновременно. Pact Broker (open-source решение для хранения и версионирования контрактов) или его коммерческая версия Pactflow решают эту проблему, храня контракты с тегами версий.
Реальный пример из практики: как сокращают регресс в 4 раза с помощью контрактов
Во многих FinTech- и e-commerce-проектах с микросервисной архитектурой команды сталкиваются с одинаковой проблемой: несколько сервисов развиваются параллельно разными командами, а перед релизом интеграционное тестирование превращается в многодневный квест.
Типичная картина: инженеры вручную поднимают общий стенд, прогоняют коллекции Postman, сверяют JSON-структуры, пытаются понять, на чьей стороне «сломался» формат. Такой регресс легко занимает два-три дня и при этом не даёт ощущения надёжности — всегда остаётся тревога, что чьи-то изменения незаметно задели соседний сервис.
В подобных ситуациях команды часто внедряют контрактное тестирование с помощью Pact.
Подход выглядит так:
сервис-потребитель в своих тестах формирует контракт (pact-файл) с описанием ожидаемого API;
этот контракт публикуется в общий репозиторий;
в CI сервиса-провайдера появляется этап верификации: сборка проверяет, что текущая версия API всё ещё соответствует ожиданиям потребителей;
если контракт нарушен — сборка падает ещё до попадания изменений на общий стенд.
В результате большая часть проблем интеграции (несовпадение форматов, обязательных полей, кодов ответа) ловится на этапе сборки, а не во время общего регресса.
На практике это приводит к заметному эффекту: существенно сокращается объём регресса, связанного с несовместимостью API.
Интересная практика, встречающаяся в высоконагруженных командах: они дополняют контрактные тесты анализом реального production-трафика. С помощью инструментов вроде WireMock записываются реальные запросы и ответы, после чего инженеры находят неочевидные кейсы и добавляют их в тесты потребителей. Так контракты постепенно начинают отражать не только «задуманное» API, но и то, как им реально пользуются в продакшене.
Этот подход позволяет убрать главный страх микросервисных команд перед релизом: «а вдруг у соседей что-то отвалится», заменяя его быстрым и автоматическим сигналом прямо в CI.
Контракты — это не только про JSON
Хотя пример выше с REST, контрактное тестирование применимо к любым асинхронным взаимодействиям: сообщения в Kafka, RabbitMQ, gRPC. Для Kafka, например, Pact поддерживает спецификацию сообщений. Вы описываете, какой формат сообщения ожидает потребитель, и провайдер верифицирует, что продюсит именно такой.
Код контракта для Kafka-сообщения:
import au.com.dius.pact.consumer.dsl.PactDslJsonBody import au.com.dius.pact.consumer.junit5.PactConsumerTestExt import au.com.dius.pact.consumer.junit5.PactTestFor import au.com.dius.pact.core.model.annotations.Pact import au.com.dius.pact.core.model.messaging.MessagePact import org.junit.jupiter.api.extension.ExtendWith @ExtendWith(PactConsumerTestExt::class) @PactTestFor(providerName = "order-service", providerType = ProviderType.ASYNCH) class OrderMessagePactTest { @Pact(consumer = "notification-service") fun orderCreatedEvent(builder: MessagePactBuilder): MessagePact { return builder .given("order created") .expectsToReceive("an order created event") .withContent( PactDslJsonBody() .integerType("orderId", 100) .stringType("status", "CREATED") ) .toPact() } }
На стороне провайдера проверяется, что реальное сообщение соответствует этому шаблону.
Что дальше? Системный подход к автоматизации на Kotlin
Контрактное тестирование — мощный инструмент, но оно не заменяет ни модульные, ни интеграционные тесты. Это дополнительный слой защиты, который позволяет командам двигаться быстро и независимо.
Когда интеграции начинают ломаться неочевидно, а тесты перестают давать уверенность, возникает простой запрос: проверять поведение системы на уровне реальных взаимодействий, а не отдельных компонентов. Дальше — выстроить полный контур автоматизации: от API и пользовательского интерфейса до нагрузочных сценариев и встраивания проверок в конвейер сборки. Такой подход последовательно разбирается в курсе «Автоматизатор тестирования на Kotlin» — с фокусом на практику и применимость в реальных проектах.
Пройдите вступительный тест, чтобы узнать, подойдет ли вам программа курса. А чтобы узнать больше о формате обучения и задать свои вопросы, приходите на бесплатные уроки:
28 апреля в 20:00. «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд». Записаться
21 мая в 20:00. «Суперсилы Kotlin для удобных UI-автотестов». Записаться