What Is Microservices Testing? Layers, Mocks and Contracts

This is lesson 6.8 of Test Data, Mocks and End-to-End API Testing, the last in the track. It pulls the track together: mocks from lesson 6.1, data from lessons 6.3 to 6.5, and the integration and journey tests from lessons 6.6 and 6.7.

What is microservices testing?

What is microservices testing? It's testing a system built from small services that deploy independently and talk over the network, and it has to answer three questions: does each service work on its own, do services still agree on how they talk to each other, and do the few journeys that cross many services still work end to end. The answer is layers, each one cheaper and more numerous than the one above it.

Why microservices change testing

In a single application, a refactor that breaks a caller fails the build. In microservices, the caller is in another repository, owned by another team, deployed on another day. Three things follow:

• The contract becomes the test boundary. Each service's API spec is a promise to every consumer. Breaking it is the most common way to break production.
• The network is part of the system. Latency, timeouts, retries and partial failures are normal, not exceptional.
• Full-system environments are expensive. Twenty services, each with its own data, rarely line up in one staging environment. Tests that need all of them are slow and flaky.

The layers of microservices testing

The shape matters more than the exact numbers: lots of fast, isolated tests at the bottom, very few slow, connected ones at the top.

A microservices testing example

Imagine the sandbox store split into three services:

• users-service owns /api/v1/users.
• catalog-service owns /api/v1/products.
• orders-service owns /api/v1/orders, and calls the other two to expand an order's user and product.

Here's how each layer applies to the orders-service:

1. Unit: the code that builds an order response from three lookups, with the lookups stubbed in-process.
2. Component: start orders-service with its own database, and point its users and catalog URLs at mock servers generated from those services' specs. Test POST /orders, GET /orders/{id}?expand=user,product, and what happens when the catalog mock answers 503 or takes two seconds.
3. Contract: on catalog-service's side, check on every merge that its real responses still match the spec the orders team generated their mock from: same fields, same types, same status codes. If catalog renames price, this fails in catalog's build, not in orders' production.
4. Integration: with real users and orders services, delete a user and check the order still reads back with user: null (lesson 6.7).
5. End-to-end: one journey after each deploy: create a user, order a product, move the order to processing (lesson 6.6).

Consumer-driven vs spec-driven contracts

There are two common ways to run layer 3:

• Consumer-driven (Pact is the best-known tool): each consumer records the requests it makes and the parts of the response it uses; the provider replays those expectations in its own build. Precise about what consumers really need, and it needs both sides to adopt the tool.
• Spec-driven: the provider's OpenAPI spec is the contract. Consumers generate mocks from it, and the provider is checked against it, with schema assertions or tools such as Schemathesis and Dredd. Easier to adopt, and only as precise as the spec.

Many teams start spec-driven and add consumer-driven contracts on their most critical integrations.

Microservices testing tools, by layer

Microservices automation testing tools only pay off when each layer runs in the pipeline at the right moment: unit, component and contract on every merge; integration on merge or deploy; end-to-end after deploy.

Common mistakes

• An end-to-end-only strategy. Slow, flaky, and it tells you a journey broke without saying which service broke it.
• Hand-written mocks. They drift from the real service; generate them from the spec and regenerate on change.
• Contract checks only on one side. The provider must check too, or the consumer's mock goes stale.
• No ownership. Every service needs a team that owns its tests and its spec.

Mocks and a contract pack in Shift-Left API

Shift-Left API takes the spec-driven route: it imports each service's spec, generates tests whose assertions come from the response schema (status codes, field presence and types), and spins up mock servers from the same spec. It doesn't run consumer-driven contracts or a Pact broker, and its mocks are stateless, so treat them as component-level stand-ins.

To run the same tests against a real service and against its mock:

1. Import https://demo.totalshiftleft.ai/openapi/rest.json. Generate mocks for Products on the Mocks page and click Start Mock Server.
2. In Project Settings → Environment Settings, keep Development on the live sandbox and add an environment on the mock server's path-based URL (lesson 9.9).
3. Make two tests on GET /api/v1/products/{id}: the Wireless Mouse (aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa), expecting 200 and a product name; and 00000000-0000-0000-0000-000000000000, expecting 404.
4. In Execution, create a Functional Test Run Pack with both tests. Test Run Packs need Professional, a trial or Enterprise.
5. Run it with Override ticked and the environment set to Development, then again with the mock environment.

On Development, both pass. On the mock, the 200 test passes and the 404 test fails: a mock generated from the spec answers every request on that path with the documented success. That's the lesson of the layers in one result. A mock is good enough to test a consumer; only the real service can prove the provider. The same pack runs from CI (lesson 9.10 covers packs and scheduling), and the API contract testing page describes the contract checks in more detail.

Try it yourself

With a trial, build the two-test pack above and run it once per environment. Then open the pack's run history and compare the two pass rates.

Recap

• What is microservices testing: testing each service alone, the contracts between services, and a few journeys across them, in layers from many fast tests to few slow ones.
• A microservices testing example: test orders-service against mocks of users and catalog, check those services against their specs, and keep one cross-service journey.
• Microservices testing tools map to layers; mocks prove the consumer, contract checks prove the provider.

For the full strategy, tools comparison and a migration case study, read microservices testing: strategy, types, tools and examples.

Next: Track 7 begins with what is CI/CD in automation testing.