Всем привет, меня зовут Сергей Прощаев, и в этой статье я расскажу про контрактное тестирование на 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-автотестов». Записаться