В современных архитектурах микросервисов приложения в значительной степени полагаются на межсервисное взаимодействие, часто через API. Крайне важно обеспечить, чтобы эти API продолжали работать должным образом во время разработки и после внесения изменений. Одним из эффективных способов добиться этого является тестирование контрактов по инициативе потребителя (CDCT). CDCT — это метод, который гарантирует, что сервисы (производители) соответствуют ожиданиям, установленным сервисами, использующими их API (потребители).

В этом руководстве мы рассмотрим, что такое CDCT, как он работает, его важность для обеспечения надежного взаимодействия микросервисов и как его можно реализовать с помощью таких инструментов, как Pact.

Что такое контрактное тестирование, ориентированное на потребителя?
Контрактное тестирование, управляемое потребителями, — это стратегия тестирования, которая гарантирует, что связь между службами в распределенной архитектуре соответствует согласованным контрактам. Оно отличается от традиционного тестирования API тем, что фокусируется на потребностях потребителей, а не просто на обеспечении правильной работы самого API. Контракт между потребителем API и поставщиком определяется ожиданиями потребителя, и этот контракт проверяется на соответствие реализации поставщика.

Ключевые термины:
• Потребитель: сервис, использующий API.
• Поставщик (производитель): служба, предоставляющая API.
• Контракт: официальное соглашение между потребителем и поставщиком, определяющее ожидаемое поведение API.

Как это работает?

1. Потребитель определяет контракт: Потребитель определяет свои ожидания относительно того, как должен вести себя API поставщика (например, какие конечные точки, форматы данных и коды состояния ответа он ожидает).
2. Контракт является общим: Потребитель делится этим контрактом с поставщиком. Этот контракт служит спецификацией того, чему должен соответствовать поставщик.
3. Поставщик проверяет контракт: Поставщик проверяет себя на соответствие контракту потребителя, гарантируя, что он соответствует ожиданиям потребителя.
4. Постоянный цикл обратной связи: Любые критические изменения в API поставщика будут обнаружены заранее, поскольку поставщик должен проверять соответствие всем контрактам потребителей. Это создает систему безопасности, гарантирующую, что изменения в поставщике не окажут негативного влияния на потребителей.

Важность тестирования контрактов, ориентированного на потребителя
В распределенных архитектурах, особенно с микросервисами, управление зависимостями между сервисами становится более сложным. CDCT помогает облегчить эту сложность несколькими способами:

1. Предотвращает сбои в производстве
Поскольку потребители определяют, что им нужно, изменения в API поставщика, которые не соответствуют ожиданиям потребителя, фиксируются на ранних стадиях разработки. Это снижает риск поломки производственных систем из-за несовместимых изменений.

2. Разделение развития
Тестирование контрактов, ориентированное на потребителя, позволяет потребителям и поставщикам развиваться независимо. Это особенно полезно, когда команды или службы развиваются отдельно. Контракты служат интерфейсом, гарантирующим, что интеграция работает должным образом, без необходимости полного интеграционного тестирования во время каждого цикла разработки.

3. Ускоренные циклы разработки
С помощью CDCT как потребитель, так и поставщик могут разрабатываться и тестироваться параллельно, что ускоряет разработку. Поставщики могут проверить соответствие контракту потребителя еще до того, как потребитель полностью реализует свою функциональность.

4. Раннее выявление нарушений контракта
Изменения поставщика, нарушающие контракт, обнаруживаются на ранних этапах процесса разработки, что позволяет разработчикам решать проблемы до того, как они станут критическими.

Как реализовать тестирование контрактов, ориентированное на потребителя
Для реализации CDCT доступно несколько инструментов, одним из самых популярных является Pact. Pact позволяет потребителям определять свои контракты, а поставщикам проверять их.

Вот пошаговое руководство по реализации CDCT с использованием Pact:
Шаг 1: Определите ожидания потребителей
Сначала в потребительском обслуживании определите договор. Обычно это включает в себя следующее:
• Конечная точка, к которой будет обращаться потребитель.
• Метод запроса (GET, POST, PUT и т. д.).
• Ожидаемое тело или параметры запроса.
• Ожидаемое тело ответа и код состояния.
Вот пример определения контракта в потребительском тесте с использованием Pact в JavaScript:

const { Pact } = require('@pact-foundation/pact');
const path = require('path');

const provider = new Pact({
    consumer: 'UserService',
    provider: 'UserAPI',
    port: 1234,
    log: path.resolve(process.cwd(), 'logs', 'pact.log'),
    dir: path.resolve(process.cwd(), 'pacts'),
});

describe('Pact Consumer Test', () => {
    beforeAll(() => provider.setup());

    afterAll(() => provider.finalize());

    it('should receive user details from the API', async () => {
        // Define the expected interaction
        await provider.addInteraction({
            state: 'user exists',
            uponReceiving: 'a request for user details',
            withRequest: {
                method: 'GET',
                path: '/users/1',
                headers: {
                    Accept: 'application/json',
                },
            },
            willRespondWith: {
                status: 200,
                headers: {
                    'Content-Type': 'application/json',
                },
                body: {
                    id: 1,
                    name: 'John Doe',
                },
            },
        });

        // Make the actual request and test
        const response = await getUserDetails(1);
        expect(response).toEqual({ id: 1, name: 'John Doe' });
    });
});

В этом примере потребитель (UserService) ожидает, что поставщик (UserAPI) вернет сведения о пользователе при выполнении запроса GET к /users/1.

Шаг 2. Публикация контракта
После прохождения потребительского теста Pact генерирует файл контракта (файл Pact), которым можно поделиться с поставщиком. Этот контракт может храниться в брокере Pact или в системе контроля версий, чтобы провайдер мог использовать его для проверки.

Шаг 3. Поставщик проверяет договор
Поставщик получает контракт и проверяет, соответствует ли он ожиданиям потребителя. Это делается путем запуска теста Pact на стороне провайдера. Вот пример проверки контракта Pact на Java:

public class ProviderTest {

    @Test
    public void testProviderAgainstPact() {
        PactVerificationResult result = new PactVerifier()
            .verifyProvider("UserAPI", "pacts/UserService-UserAPI.json");

        assertThat(result, instanceOf(PactVerificationResult.Ok.class));
    }
}

Поставщик запускает этот тест, чтобы убедиться в соответствии контракту, указанному потребителем.

Шаг 4. Непрерывная интеграция
Как только CDCT будет интегрирован в ваш конвейер CI/CD, каждый раз при изменении контракта поставщик сможет автоматически проверять контракт. Это гарантирует, что изменения API не нарушат ожиданий потребителя, обеспечивая безопасность для обеих команд.

Лучшие практики CDCT

1. Малые, целенаправленные контракты: Убедитесь, что ваши контракты небольшие и ориентированы только на потребности потребителя. Это предотвращает ненужную сложность контракта и упрощает проверку.
2. Версии контракта: Всегда устанавливайте версии своих контрактов. Это позволяет поставщикам обрабатывать несколько версий одного и того же контракта, помогая поддерживать разных потребителей на разных этапах разработки.
3. Независимое развертывание: Убедитесь, что CDCT является частью вашего конвейера CI/CD. Любые изменения в потребителе или поставщике должны вызывать тестирование контракта, чтобы избежать нарушения производственной среды.
4. Используйте Pact Broker: Pact Broker — это центральный репозиторий, в котором хранятся ваши контракты и который позволяет как потребителям, так и поставщикам получать их. Он также предоставляет пользовательский интерфейс для визуализации версий контрактов и зависимостей.

Когда использовать тестирование контрактов, ориентированное на потребителя
CDCT особенно полезен, когда:
• У вас есть микросервисы или распределенные архитектуры с множеством взаимодействующих сервисов.
• Команды, работающие над различными сервисами, должны разрабатывать независимо друг от друга без частого интеграционного тестирования.
• Контракты API, скорее всего, будут часто меняться, и вы хотите избежать нарушения ожиданий потребителей.
• Вам нужны быстрые циклы обратной связи, чтобы обнаружить нарушения контракта на ранних этапах процесса разработки.

Заключение
Тестирование контрактов, управляемое потребителями, предлагает надежный способ гарантировать, что сервисы в распределенной системе эффективно взаимодействуют без внесения изменений. Сосредоточив внимание на ожиданиях потребителей и проверяя поставщика на их соответствие, CDCT помогает командам развиваться независимо, обеспечивая при этом стабильность. Независимо от того, создаете ли вы микросервисы, приложения на основе API или распределенные системы, включение CDCT в вашу стратегию тестирования повысит надежность и масштабируемость ваших сервисов.