Contract Testing

This is the predominant pattern in contract testing. The consumer of an API (e.g., a frontend or another service) defines its expectations in a contract file. This contract specifies the required request formats and the expected response schemas. The provider (the API service) then validates its implementation against this contract. This ensures the provider does not make changes that would break its consumers, as the contract acts as a formal agreement. Tools like Pact and Spring Cloud Contract implement this pattern.

• Key Benefit: Shifts testing left and prevents breaking changes.
• Example: A mobile app (consumer) defines it needs a user object with an id and email field. The backend (provider) test fails if it changes the email field name to emailAddress.

In this pattern, the provider of the API authors and publishes the contract specification, often using a standard like OpenAPI (Swagger). Consumers can then use this contract to generate client code or mock servers for their own development and testing. While less strict than consumer-driven contracts for preventing breaking changes, it is excellent for API documentation and establishing a clear source of truth for the service's capabilities.

• Key Benefit: Provides authoritative, machine-readable API documentation.
• Workflow: The provider maintains an openapi.yaml file; CI pipelines can automatically generate server stubs and client SDKs from it.

The contract file itself—whether JSON Schema, Pact JSON, or OpenAPI YAML—becomes the authoritative specification for the interaction. It is version-controlled and treated as code. All testing and validation revolve around this artifact. Neither the consumer's mock tests nor the provider's verification tests rely on implicit assumptions; they both execute against the explicit contract. This eliminates the drift between documented APIs and their actual implementation.

A primary goal of contract testing is to enable teams to develop and test their services in isolation. The consumer team can run its full test suite using a mock provider generated from the contract, without needing the real provider running. Conversely, the provider team can verify its implementation meets all consumer contracts without spinning up every consumer. This parallel development accelerates release cycles and is a key enabler for microservices and continuous delivery.

Contract testing validates the messages (HTTP requests/responses, events) passed between services, not their internal business logic. It answers: "Does the response match the agreed schema?" and "Are the required headers present?" It does not test whether the provider's database query is correct or if the consumer's UI renders properly. This separation of concerns aligns with the integration contract concept and complements unit and end-to-end testing, fitting neatly into the Test Pyramid.

For contract testing to be effective, it must be automated and integrated into the Continuous Integration/Continuous Delivery pipeline. On a consumer code change, its contract tests run against the mock provider. Before a provider deploys, its build pipeline should fetch the latest contracts from all its consumers (often from a Pact Broker or artifact repository) and run verification tests. A failed verification should break the build, preventing a deployment that would break an integrated service.

The practice of creating simulated versions of APIs to mimic their behavior for development and testing without relying on live services. While contract testing validates agreements, mocking simulates them.

• Purpose: Enables parallel development and testing in isolation.
• Relationship to Contract Testing: Mock servers can be generated from a contract (e.g., an OpenAPI spec or Pact contract), ensuring the mock behaves exactly as the real service is expected to.

A more advanced form of mocking that emulates the behavior of complex, stateful, or hard-to-access components (like mainframes, third-party APIs, or databases). It provides a more realistic and controllable substitute for testing.

• Scope: Broader than simple API mocking, often virtualizing entire backend systems with complex behaviors and data states.
• Use Case: Essential for integration and performance testing when dependent systems are unavailable, costly, or unreliable.

A generic term from unit testing for any object that replaces a real component during testing. Understanding this hierarchy is key to selecting the right isolation technique.

• Types Include:
  • Dummy: Object passed around but never used.
  • Fake: Working implementation with shortcuts (e.g., in-memory database).
  • Stub: Provides canned answers to calls.
  • Mock: Pre-programmed with expectations which it verifies.
  • Spy: Records interactions for later verification.
• Context: An API mock or virtual service is a form of test double used at the integration level.

The practice of executing automated tests as an integral part of the software delivery pipeline to get immediate feedback on release readiness. Contract testing is a cornerstone of this practice for microservices.

• Integration: Consumer and provider contract tests are run automatically in Continuous Integration (CI) pipelines.
  • A consumer build fails if it cannot generate its contract.
  • A provider build fails if it cannot verify all published consumer contracts.
• Outcome: Prevents deploy-time integration failures, enabling safe, independent deployment of services.