Contract testing: как тестировать микросервисы без интеграционных тестов и ускорить CI/CD

Пятница, 18:30. Команда А деплоит новую версию Order Service. Маленькое изменение в API: поле renamed_at вместо renamedat. Казалось бы, мелочь. Суббота, 8:00 утра. Мобильное приложение команды Б перестало работать. Заказы не создаются. Пользователи злятся. Инцидент. Все выходные команды пытаются понять что сломалось.

В чём проблема? У команды А есть unit тесты (проходят). У команды Б есть интеграционные тесты (проходят, но тестируют против старой версии). End-to-end тесты есть, но они запускаются раз в день и постоянно падают по причинам не связанным с кодом.

Вторник. Команда С запускает интеграционный тест для Payment Service. Тест падает. Почему? Потому что User Service сейчас деплоится и недоступен. Блокировка CI/CD на 15 минут. В пятый раз за день.

Знакомо?

Микросервисная архитектура дала нам независимые деплойменты, масштабируемость, технологическое разнообразие. Но она же породила кошмар интеграционного тестирования. Когда у вас 10 сервисов, это 45 потенциальных интеграций. Когда 100 сервисов, это уже 4950 интеграций. Протестировать все комбинации в реальном окружении невозможно.

Contract testing решает эту проблему. Вместо тестирования всех сервисов вместе, вы тестируете контракты между ними. Быстро. Изолированно. Надёжно. Без зависимостей от окружения.

В этой статье разбираемся как работает contract testing на практике. Без теории из учебников. С реальными примерами на Pact. С интеграцией в CI/CD. С объяснением когда это работает и когда нет.

1. Проблема интеграционного тестирования микросервисов

Классический подход: интеграционные тесты

В монолитном приложении интеграционное тестирование относительно просто. Поднимаете приложение, тестируете. Всё в одном процессе.

В микросервисах всё сложнее. Типичная схема интеграционного тестирования:

1. Поднимаете тестовое окружение со всеми зависимостями

2. Запускаете все нужные сервисы

3. Настраиваете тестовые данные

4. Выполняете тесты

5. Чистите данные

Проблемы этого подхода:

1. Медленно

Интеграционный тест занимает минуты, иногда десятки минут. Поднять 5 сервисов, базы данных, очереди сообщений, настроить данные. Один тест запускается 3-5 минут. Сотня тестов: 300-500 минут. Это 5-8 часов.

2. Хрупко (flaky)

Тесты падают не потому что код плохой, а потому что:

• Один из сервисов не поднялся вовремя

• Сеть глюканула

• База данных заблокировала запись

• Кто-то задеплоил новую версию зависимости

• Тестовые данные в неожиданном состоянии

3. Дорого в поддержке

Нужно поддерживать тестовое окружение. Когда у вас 50 микросервисов, это отдельная команда DevOps только для поддержки test environments.

4. Блокирующие зависимости

Команда А не может задеплоить свой сервис потому что команда Б сейчас обновляет свой сервис в test environment. Или потому что сервис команды В упал и никто не знает почему.

5. Не scale

Количество интеграций растёт как n*(n-1)/2. Для 10 сервисов: 45 интеграций. Для 50: 1225. Для 100: 4950. Невозможно протестировать все комбинации.

Реальная статистика

Из опыта команд переходящих на contract testing:

• Интеграционные тесты занимают 30-60% времени CI/CD pipeline

• 50-70% падений тестов это false positives (инфраструктурные проблемы, не код)

• Среднее время починки flaky теста: 2-4 часа

• Стоимость поддержки test environment: $10k-50k в месяц для средней компании

E2E тесты: ещё хуже

End-to-end тесты тестируют весь флоу пользователя через все сервисы. Они нужны, но:

• Ещё медленнее (10-30 минут на один тест)

• Ещё более flaky

• Сложно отлаживать (где именно сломалось?)

• Не дают быстрого feedback loop

Что в итоге

Типичная ситуация в компаниях с микросервисами:

• CI/CD занимает 45 минут (из них 30 минут интеграционные тесты)

• Интеграционные тесты падают в 30% случаев

• Разработчики игнорируют падения ("опять инфра")

• Баги в интеграциях всё равно попадают в продакшн

• Деплойменты боятся делать по пятницам

Contract testing меняет эту картину радикально.

2. Что такое contract testing

Определение

Contract testing - это подход к тестированию интеграций между сервисами, где вместо тестирования всех сервисов вместе, вы тестируете каждый сервис изолированно против согласованного контракта.

Контракт описывает: "Когда consumer отправляет такой запрос, provider должен ответить таким ответом".

Ключевые понятия:

• Consumer (потребитель): Сервис который делает запрос. Например, Frontend или Order Service

• Provider (поставщик): Сервис который отвечает на запрос. Например, User API или Payment Service

• Contract (контракт): Документ описывающий ожидания consumer от provider

• Pact: Самый популярный инструмент для consumer-driven contract testing

Как это работает (упрощённо):

1. Consumer пишет тест с ожиданиями: "Когда я запрашиваю GET /users/123, я жду 200 OK и JSON с полями id, name, email"

2. Тест запускается против mock provider

3. Генерируется контракт (JSON файл) с описанием взаимодействия

4. Provider забирает контракт и проверяет: "Могу ли я выполнить эти ожидания?"

5. Provider запускает свой реальный код против контракта

6. Если provider не может выполнить контракт, его тесты падают

Главное преимущество

Сервисы тестируются изолированно. Не нужно поднимать весь зоопарк. Consumer тестируется без реального provider. Provider тестируется без реального consumer.

Аналогия

Представьте два завода:

• Завод А делает USB разъёмы

• Завод Б делает USB кабели

Традиционный подход: привезти кабель на завод разъёмов и проверить что подходит.

Contract testing: есть спецификация USB. Завод А тестирует что разъём соответствует спецификации. Завод Б тестирует что кабель соответствует спецификации. Если оба соответствуют, они совместимы. Не нужно везти физически.

3. Consumer-driven contract testing с Pact

Почему consumer-driven

В consumer-driven подходе контракт определяет consumer, а не provider. Почему?

• Consumer знает что ему нужно

• Provider может иметь 100 возможностей, но consumer использует только 5

• Тестируем только то что реально используется

• Provider свободен менять всё что не в контракте

Установка Pact (Node.js пример)

npm install --save-dev @pact-foundation/pact

Пример: Order Service (consumer) и User Service (provider)

Order Service создаёт заказы и нужно получить информацию о пользователе от User Service.

Шаг 1: Consumer пишет тест

Файл: order-service/test/user-api.pact.test.js

const { PactV3 } = require('@pact-foundation/pact');
const { getUserById } = require('../src/userClient');

const provider = new PactV3({
    consumer: 'OrderService',
    provider: 'UserService'
});

describe('User API Contract', () => {
    test('получение пользователя по ID', async () => {
        // Определяем ожидания
        await provider
            .given('пользователь с ID 123 существует')
            .uponReceiving('запрос пользователя по ID')
            .withRequest({
                method: 'GET',
                path: '/api/users/123',
                headers: {
                    'Accept': 'application/json'
                }
            })
            .willRespondWith({
                status: 200,
                headers: {
                    'Content-Type': 'application/json'
                },
                body: {
                    id: 123,
                    name: 'John Doe',
                    email: 'john@example.com'
                }
            });

        // Выполняем тест
        await provider.executeTest(async (mockServer) => {
            const user = await getUserById(mockServer.url, 123);
            
            expect(user.id).toBe(123);
            expect(user.name).toBe('John Doe');
            expect(user.email).toBe('john@example.com');
        });
    });
});

Что происходит:

1. Pact поднимает mock server

2. Настраивает его отвечать согласно контракту

3. Выполняет ваш код против mock server

4. Генерирует pact файл (контракт) в JSON

Шаг 2: Генерируется pact файл

Файл: pacts/OrderService-UserService.json

{
  "consumer": {
    "name": "OrderService"
  },
  "provider": {
    "name": "UserService"
  },
  "interactions": [
    {
      "description": "запрос пользователя по ID",
      "providerState": "пользователь с ID 123 существует",
      "request": {
        "method": "GET",
        "path": "/api/users/123",
        "headers": {
          "Accept": "application/json"
        }
      },
      "response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json"
        },
        "body": {
          "id": 123,
          "name": "John Doe",
          "email": "john@example.com"
        }
      }
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "3.0.0"
    }
  }
}

Шаг 3: Provider верифицирует контракт

Файл: user-service/test/pact-verification.test.js

const { Verifier } = require('@pact-foundation/pact');
const path = require('path');
const { startServer, stopServer } = require('../src/server');

describe('Pact Verification', () => {
    let server;
    const PORT = 3001;

    beforeAll(async () => {
        server = await startServer(PORT);
    });

    afterAll(async () => {
        await stopServer(server);
    });

    test('валидирует контракт от OrderService', async () => {
        const verifier = new Verifier({
            providerBaseUrl: `http://localhost:${PORT}`,
            pactUrls: [
                path.resolve(__dirname, 
                    '../../order-service/pacts/OrderService-UserService.json')
            ],
            provider: 'UserService',
            providerVersion: '1.0.0',
            
            // Provider states
            stateHandlers: {
                'пользователь с ID 123 существует': async () => {
                    // Настройка тестовых данных
                    await setupTestUser({
                        id: 123,
                        name: 'John Doe',
                        email: 'john@example.com'
                    });
                }
            }
        });

        await verifier.verifyProvider();
    });
});

Что происходит:

1. Provider запускает свой реальный сервис

2. Pact читает контракт

3. Для каждого взаимодействия в контракте:

   • Устанавливает state (например, создаёт тестового пользователя)

   • Делает реальный HTTP запрос к provider

   • Сравнивает ответ с ожиданиями в контракте

4. Если всё совпадает, тест проходит

Важно

Provider тестируется изолированно. Не нужен реальный OrderService. Не нужна база данных (можно использовать in-memory или моки). Тест занимает секунды, не минуты.

4. Pact Broker: центральное хранилище контрактов

Проблема без broker

В предыдущем примере мы передавали pact файл вручную. Но в реальности:

• Consumer и Provider в разных репозиториях

• Разные команды

• Разные CI/CD пайплайны

• Множество версий каждого сервиса

Как передавать контракты? Через Git? Email? Slack?

Решение: Pact Broker

Pact Broker это центральное хранилище для контрактов. Он:

• Хранит все версии всех контрактов

• Показывает какие версии consumer совместимы с какими версиями provider

• Интегрируется с CI/CD

• Предоставляет UI для просмотра контрактов

• Показывает матрицу совместимости

Запуск Pact Broker (Docker)

version: '3'
services:
  postgres:
    image: postgres:13
    environment:
      POSTGRES_USER: pact
      POSTGRES_PASSWORD: pact
      POSTGRES_DB: pact_broker
    ports:
      - "5432:5432"

  pact-broker:
    image: pactfoundation/pact-broker:latest
    ports:
      - "9292:9292"
    environment:
      PACT_BROKER_DATABASE_URL: "postgres://pact:pact@postgres/pact_broker"
      PACT_BROKER_BASIC_AUTH_USERNAME: admin
      PACT_BROKER_BASIC_AUTH_PASSWORD: admin
    depends_on:
      - postgres

Запуск: docker-compose up

Broker доступен на http://localhost:9292

Публикация контракта в Broker (Consumer)

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

const publish = async () => {
    const publisher = new Publisher({
        pactBroker: 'http://localhost:9292',
        pactBrokerUsername: 'admin',
        pactBrokerPassword: 'admin',
        pactFilesOrDirs: [path.resolve(__dirname, '../pacts')],
        consumerVersion: process.env.GIT_COMMIT || '1.0.0',
        tags: ['main', 'dev']
    });

    await publisher.publishPacts();
};

publish();

Добавляем в package.json:

{
  "scripts": {
    "test:pact": "jest --testMatch='**/*.pact.test.js'",
    "pact:publish": "node test/publish-pacts.js"
  }
}

Верификация из Broker (Provider)

const verifier = new Verifier({
    providerBaseUrl: `http://localhost:${PORT}`,
    
    // Вместо локального файла - broker
    pactBrokerUrl: 'http://localhost:9292',
    pactBrokerUsername: 'admin',
    pactBrokerPassword: 'admin',
    
    provider: 'UserService',
    providerVersion: process.env.GIT_COMMIT || '1.0.0',
    
    // Верифицируем все контракты от consumers с тегом 'main'
    consumerVersionSelectors: [
        { tag: 'main', latest: true }
    ],
    
    publishVerificationResult: true,
    stateHandlers: { /* ... */ }
});

await verifier.verifyProvider();

Can I Deploy?

Pact Broker предоставляет CLI для проверки совместимости:

# Можно ли деплоить OrderService версии abc123 в production?
pact-broker can-i-deploy \
  --pacticipant OrderService \
  --version abc123 \
  --to-environment production

Ответ:

Computer says yes \o/ 

CONSUMER       | C.VERSION | PROVIDER    | P.VERSION | SUCCESS?
---------------|-----------|-------------|-----------|----------
OrderService   | abc123    | UserService | def456    | true

All required verification results are published and successful

Или:

Computer says no :(

CONSUMER       | C.VERSION | PROVIDER    | P.VERSION | SUCCESS?
---------------|-----------|-------------|-----------|----------
OrderService   | abc123    | UserService | def456    | false

Reason: Verification failed

Интеграция в CI/CD

GitHub Actions пример:

name: Contract Tests

on: [push]

jobs:
  consumer-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
      
      - run: npm install
      - run: npm run test:pact
      
      - name: Publish pacts
        run: npm run pact:publish
        env:
          GIT_COMMIT: ${{ github.sha }}
      
      - name: Can I deploy?
        run: |
          pact-broker can-i-deploy \
            --pacticipant OrderService \
            --version ${{ github.sha }} \
            --to-environment production

5. Сравнение с другими видами тестирования

Тестовая пирамида для микросервисов

Классическая пирамида:

• 70% Unit тесты

• 20% Integration тесты

• 10% E2E тесты

Современная пирамида для микросервисов:

• 50% Unit тесты

• 30% Contract тесты

• 15% Integration тесты (внутри сервиса)

• 5% E2E тесты (критические флоу)

Что заменяется contract тестами

Contract тесты заменяют:

• Интеграционные тесты между сервисами

• API compatibility тесты

• Smoke тесты интеграций

Contract тесты НЕ заменяют:

• Unit тесты бизнес логики

• Integration тесты с базой данных

• E2E тесты критических флоу

• Performance тесты

• Security тесты

6. Практический пример: e-commerce система

Архитектура

Упрощённая e-commerce система:

• Frontend: React приложение

• Order Service: Управление заказами

• User Service: Данные пользователей

• Product Service: Каталог товаров

• Payment Service: Обработка платежей

Интеграции:

• Frontend → Order Service

• Order Service → User Service

• Order Service → Product Service

• Order Service → Payment Service

Сценарий: создание заказа

1. Frontend → Order Service контракт

Consumer test (Frontend):

test('создание заказа', async () => {
    await provider
        .given('пользователь 123 существует, товар 456 доступен')
        .uponReceiving('запрос создания заказа')
        .withRequest({
            method: 'POST',
            path: '/api/orders',
            headers: {
                'Content-Type': 'application/json',
                'Authorization': 'Bearer token123'
            },
            body: {
                userId: 123,
                items: [{
                    productId: 456,
                    quantity: 2
                }]
            }
        })
        .willRespondWith({
            status: 201,
            headers: {
                'Content-Type': 'application/json'
            },
            body: {
                orderId: 789,
                status: 'pending',
                total: 99.98
            }
        });

    await provider.executeTest(async (mockServer) => {
        const order = await createOrder(mockServer.url, {
            userId: 123,
            items: [{ productId: 456, quantity: 2 }]
        });
        
        expect(order.orderId).toBe(789);
        expect(order.status).toBe('pending');
    });
});

2. Order Service → User Service контракт

Consumer test (Order Service):

test('проверка существования пользователя', async () => {
    await provider
        .given('пользователь 123 существует')
        .uponReceiving('запрос проверки пользователя')
        .withRequest({
            method: 'GET',
            path: '/api/users/123/exists'
        })
        .willRespondWith({
            status: 200,
            body: {
                exists: true
            }
        });

    await provider.executeTest(async (mockServer) => {
        const exists = await userClient.checkUserExists(
            mockServer.url, 
            123
        );
        
        expect(exists).toBe(true);
    });
});

3. CI/CD процесс

Frontend pipeline:

1. Unit тесты

2. Contract тесты (генерируют pact)

3. Публикация pact в broker

4. Can-I-Deploy проверка

5. Деплой если всё ок

Order Service pipeline:

1. Unit тесты

2. Contract тесты как consumer (генерируют pacts для User/Product/Payment)

3. Contract тесты как provider (верифицируют pact от Frontend)

4. Публикация результатов в broker

5. Can-I-Deploy проверка

6. Деплой если всё ок

Время выполнения:

Ускорение CI/CD в 4.6 раза!

7. Provider States: управление тестовыми данными

Проблема

В контракте написано: "При запросе GET /users/123 вернуть пользователя John". Но что если в базе provider нет пользователя с ID 123?

Решение: Provider States

Provider state - это предусловие которое должно быть выполнено перед тестом.

Consumer указывает state:

.given('пользователь с ID 123 и именем John существует')

Provider реализует state handler:

stateHandlers: {
    'пользователь с ID 123 и именем John существует': async () => {
        // Создаём тестовые данные
        await db.users.create({
            id: 123,
            name: 'John Doe',
            email: 'john@example.com',
            createdAt: '2024-01-01'
        });
    },
    
    'пользователь с ID 123 не существует': async () => {
        // Удаляем если существует
        await db.users.delete({ id: 123 });
    },
    
    'база данных пуста': async () => {
        await db.users.deleteAll();
        await db.orders.deleteAll();
    }
}

Best practices для states:

1. Используйте in-memory базу для тестов (SQLite, H2)

2. Или моки если база не нужна

3. State должен быть идемпотентным (можно вызывать несколько раз)

4. Очищайте данные после каждого теста

5. Используйте фабрики для создания данных

Пример с фабрикой:

const UserFactory = {
    create: (overrides = {}) => ({
        id: 123,
        name: 'John Doe',
        email: 'john@example.com',
        role: 'customer',
        ...overrides
    })
};

stateHandlers: {
    'пользователь с ID 123 существует': async () => {
        const user = UserFactory.create({ id: 123 });
        await db.users.insert(user);
    },
    
    'пользователь 123 это админ': async () => {
        const admin = UserFactory.create({ 
            id: 123, 
            role: 'admin' 
        });
        await db.users.insert(admin);
    }
}

8. Типичные ошибки и как их избежать

Ошибка 1: Слишком детальные контракты

Плохо:

body: {
    id: 123,
    name: 'John Doe',
    email: 'john@example.com',
    createdAt: '2024-01-15T10:30:00Z',
    updatedAt: '2024-01-20T15:45:30Z',
    lastLoginAt: '2024-01-25T08:20:15Z',
    preferences: {
        language: 'en',
        timezone: 'UTC',
        newsletter: true
    }
}

Проблема: Consumer не использует половину полей. Если provider изменит формат lastLoginAt, контракт сломается хотя consumer это не волнует.

Хорошо:

body: {
    id: 123,
    name: like('John Doe'),
    email: like('john@example.com')
}

Тестируйте только то что реально используется.

Ошибка 2: Контракты вместо E2E тестов

Contract тесты проверяют интеграции между двумя сервисами. Они НЕ проверяют end-to-end флоу.

Пример: У вас есть контракты:

• Frontend → Order Service ✓

• Order Service → Payment Service ✓

• Payment Service → Bank API ✓

Все контракты проходят. Но полный флоу "пользователь создаёт заказ и платит" может не работать из-за проблем в бизнес логике или последовательности вызовов.

Решение: Несколько критичных E2E тестов всё равно нужны.

Ошибка 3: Не обновлять контракты

Consumer меняет код, но забывает обновить contract тесты. Контракт устаревает.

Решение:

• Contract тесты в том же CI pipeline что и unit тесты

• Code review должен проверять обновление контрактов

• Can-I-Deploy перед каждым деплоем

Ошибка 4: Provider states сложные и нестабильные

Плохо:

stateHandlers: {
    'заказ создан': async () => {
        await createUser();
        await createProduct();
        await createInventory();
        await createPaymentMethod();
        await createOrder();
        await processPayment();
        // 10 минут setup
    }
}

Хорошо:

stateHandlers: {
    'заказ 789 существует': async () => {
        await db.orders.insert({
            id: 789,
            status: 'pending'
        });
    }
}

Минимальный setup. Используйте моки или in-memory базу.

Ошибка 5: Не делиться контрактами между командами

Provider команда не знает что consumer ожидает. Consumer команда не знает что provider может предоставить.

Решение:

• Pact Broker с UI

• Регулярные sync встречи между командами

• Автоматические уведомления в Slack когда контракт меняется

• Документация генерируется из контрактов

9. Альтернативы Pact

Spring Cloud Contract пример

Контракт (Groovy DSL):

Contract.make {
    description "Получение пользователя по ID"
    request {
        method GET()
        url '/api/users/123'
    }
    response {
        status 200
        headers {
            contentType applicationJson()
        }
        body([
            id: 123,
            name: 'John Doe',
            email: 'john@example.com'
        ])
    }
}

Spring Cloud Contract генерирует:

• Provider тесты автоматически

• Stubs для consumer

• Pact файлы (совместимость с Pact)

10. Чек-лист внедрения contract testing

Подготовка (1-2 недели):

1. ☐ Выбрать инструмент (Pact, Spring Cloud Contract)

2. ☐ Поднять Pact Broker или использовать Pactflow (SaaS)

3. ☐ Определить критичные интеграции для начала

4. ☐ Обучить команды основам contract testing

5. ☐ Настроить CI/CD интеграцию

Пилот (2-4 недели):

1. ☐ Выбрать 1-2 интеграции для пилота

2. ☐ Написать первые contract тесты

3. ☐ Настроить публикацию в broker

4. ☐ Настроить верификацию

5. ☐ Добавить can-i-deploy в pipeline

6. ☐ Собрать обратную связь

Масштабирование (2-3 месяца):

1. ☐ Покрыть все критичные интеграции

2. ☐ Обучить все команды

3. ☐ Стандартизировать подходы (шаблоны, best practices)

4. ☐ Настроить мониторинг контрактов

5. ☐ Удалить дублирующие интеграционные тесты

Метрики успеха:

Заключение

Contract testing не серебряная пуля. Это инструмент который решает конкретную проблему: тестирование интеграций между микросервисами.

Когда contract testing работает отлично:

• Микросервисная архитектура с 5+ сервисами

• Независимые команды владеющие разными сервисами

• Частые деплойменты

• Проблемы с flaky интеграционными тестами

• Медленный CI/CD из-за интеграционных тестов

Когда contract testing избыточен:

• Монолит или 2-3 сервиса

• Одна команда владеет всем

• Редкие релизы

• Интеграционные тесты работают стабильно и быстро

Главные выводы:

1. Contract testing заменяет интеграционные тесты между сервисами, не E2E тесты

2. Consumer определяет контракт (consumer-driven)

3. Тестирование изолированное, без реальных зависимостей

4. Pact Broker - центральное хранилище контрактов

5. Can-I-Deploy проверка перед каждым деплоем

6. CI/CD ускоряется в 3-5 раз

7. Уменьшение flaky тестов до минимума

Contract testing - это не про замену всех тестов одним инструментом. Это про правильное распределение ответственности между разными уровнями тестирования. Unit тесты проверяют бизнес логику. Contract тесты проверяют интеграции. E2E тесты проверяют критичные флоу.

Начните с пилота на 1-2 интеграциях. Измерьте результаты. Масштабируйте на остальные сервисы. Через 3 месяца ваш CI/CD будет работать в разы быстрее, а количество поломок интеграций в продакшене стремится к нулю.

Тестируйте контракты, а не реализацию. Тогда ваши микросервисы будут эволюционировать независимо без страха что-то сломать.

А лучшие вакансии для тестировщиков QA ищите на hirehi.ru