Continuous Testing and Contract Testing: Techniques and Practices

Continuous testing enables fast feedback, preventing developers from having to retrieve weeks‑old code to fix defects and ensuring that testing is neither excessive nor insufficient.

Contract testing (first mentioned by Martin Fowler) arose from the drawbacks of test doubles, which replace real dependencies to speed up and stabilize tests.

In modern development, external service dependencies often block testing; test doubles mitigate this risk by providing an API that matches the real component without replicating its internal logic.

While test doubles improve efficiency, they are not a complete substitute for real system integration tests, and they belong to a broader class of decoupling techniques.

Table 5‑1 classifies test doubles.

When two teams develop Service1 and Service2, Service1 may rely on Service2; using a test double for Service2 can avoid network or stability issues during testing.

However, with short development cycles, if Service2 evolves while Service1 still uses an outdated test double, integration mismatches can delay projects.

In the microservice era, the provider‑consumer model gave rise to consumer‑driven contract testing (CDCT).

Contract testing defines tests from the consumer’s perspective, where the consumer provides a contract that the provider must satisfy, allowing the provider to change implementations without affecting the consumer as long as the contract is met.

Contract testing verifies that external service interfaces meet consumer expectations, focusing on business value delivery.

The most popular contract testing framework is Pact; its workflow is shown below.

After using Pact, consumer tests run as usual, and Pact records all provider requests into a JSON file, which becomes the consumer contract.

When testing the provider, the recorded contract is used as input, allowing verification that the provider satisfies the consumer contract without re‑executing consumer tests; contract testing sits between unit and integration testing.

Pact is suitable when teams can control both consumer and provider development and drive consumer‑driven development.

Not suitable when tests need to call public APIs or OAuth services.

Not suitable when provider and consumer lack good communication channels.

Not suitable for functional testing of the provider.

Not suitable when different inputs produce the same output, failing to verify behavior.

Not suitable when test inputs depend on previous test results.

FunTester Original Recommendations~ FunTester Manifesto (ChatGPT version) 2021 Original Collection 2022 Original Collection API Functional Testing Series Performance Testing Series Groovy Series Java, Groovy, Go, Python Unit Testing & White‑Box FunTester Community Highlights Testing Theory Soup FunTester Video Series Case Studies: Solutions, Bugs, Crawlers UI Automation Series Testing Tools Series -- By FunTester