Как правильно запускать тестирование контрактов?

Тестирование контрактов можно запускать разными способами в зависимости от архитектуры и выбранных инструментов.

Основные подходы:

• Во время сборки (Build Time): Тесты запускаются как часть CI/CD пайплайна после сборки сервиса. Это позволяет обнаружить ошибки интеграции до деплоя.

• После развертывания (Deployment Time): Тесты запускаются после развертывания сервиса на тестовый или стейджинговый стенд. Это более реалистично, но может привести к обнаружению проблем позже.

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

• По запросу (On Demand): Тесты запускаются вручную при необходимости, например, перед релизом или после внесения значительных изменений.

Инструменты и подходы:

• Pact: Популярный фреймворк для Consumer-Driven Contract Testing.

  • Консьюмер пишет тесты, которые определяют ожидаемый формат данных.
  • Генерируются контракты (Pact files).
  • Провайдер (сервис, предоставляющий API) верифицирует эти контракты, убеждаясь, что он соответствует ожиданиям консьюмера.
  • Запуск: typically as part of both consumer's and provider's build pipeline.

• Swagger/OpenAPI: Спецификация API может быть использована для генерации и запуска тестов.

  • Инструменты вроде Swagger Codegen или Stoplight могут генерировать тестовый код на основе спецификации.
  • Тесты проверяют соответствие ответов спецификации.
  • Запуск: может быть интегрирован в CI/CD.

• Собственные фреймворки: Создание кастомных решений для тестирования контрактов, используя стандартные клиентские библиотеки и фреймворки для тестирования (например, JUnit, TestNG, Pytest).

  • Тесты явно вызывают API и проверяют структуру и содержимое ответов.
  • Запуск: гибко настраивается в CI/CD.

Рекомендации по правильному запуску:

1. Интеграция в CI/CD: Наиболее эффективно запускать тесты контрактов в рамках CI/CD пайплайна. Это обеспечивает автоматическое обнаружение проблем.
2. Разделение по типам тестов: Разделите тесты на "Contract Tests" в вашем тестовом наборе.
3. Тестовая среда: Желательно иметь отдельную тестовую среду для тестирования контрактов, обеспечивающую стабильность зависимостей.
4. Отчеты: Генерируйте подробные отчеты о результатах выполнения тестов контрактов.
5. Уведомления: Настройте уведомления при падении тестов.

Пример интеграции в CI (Pact с Maven):

<!-- pom.xml -->
<build>
    <plugins>
        <plugin>
            <groupId>au.com.dius</groupId>
            <artifactId>pact-maven-plugin</artifactId>
            <version>4.6.0</version> // Укажите актуальную версию
            <configuration>
                <pactBrokerUrl>${pact.broker.url}</pactBrokerUrl>
                <projectVersion>${project.version}</projectVersion>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>publish</goal> // Публикация pact-файлов
                        <goal>verify</goal>   // Верификация контрактов
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Пример в GitLab CI (.gitlab-ci.yml):

# .gitlab-ci.yml
image: maven:latest # Или другой образ

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - mvn clean package

contract_test:
  stage: test
  script:
    - mvn verify
  artifacts:
    paths:
      - target/pact/reports/

deploy:
  stage: deploy
  script:
    - echo "Deploying..."
  when: manual # Пример ручного деплоя после тестов