API contract testing на собеседовании системного аналитика

Зачем contract testing

В микросервисной архитектуре — provider меняет API → consumer breaks. E2E tests slow, не покрывают.

Contract testing — fast verification что services совместимы.

Provider-driven

Provider defines OpenAPI / contract. Consumer must match.

1. Provider publishes OpenAPI 3.1.
2. Consumer integrates.
3. CI каждого consumer tests against provider's OpenAPI.

Pros: simple, single source of truth.

Cons: consumer needs могут не fit. Provider changes без warning.

Consumer-driven (Pact)

Consumer defines expectations. Provider verifies.

1. Consumer пишет integration tests с Pact mock.
2. Tests generate "contract" (JSON file).
3. Contract uploaded to Pact Broker.
4. Provider's CI verifies — its API satisfies all consumers' contracts.

Pros: consumers protected. Provider visible — что consumers fact need.

Cons: complexity setup. Pact Broker обязателен.

В РФ менее популярен, чем provider-driven.

OpenAPI testing

Tools verify implementation matches OpenAPI.

• Schemathesis. Generate tests из OpenAPI, run против provider.
• Dredd. Verify HTTP API против OpenAPI / API Blueprint.
• Spectral. Lint OpenAPI.

CI pipeline runs автоматически.

Schema validation

Runtime validation — request / response match schema.

Server-side. При получении request — validate.

Client-side. При получении response — validate (catches provider bugs).

Tools: AJV (JSON Schema), Pydantic (Python), Zod (TS).

В contract testing — гарантирует что real responses match published schema.

Связанные темы

• OpenAPI и Swagger для SA
• REST API для SA
• Виды тестирования для SA
• API Gateway и BFF для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на документации Pact / Schemathesis.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.