The Complete Guide to Microservices Testing: From Unit Tests to Production

Microservices testing is the practice of checking that each service in a distributed system works on its own, and that the services keep working when they call each other. It exists because a microservices architecture moves correctness out of any single codebase and into the network calls between services that different teams build, deploy, and change on different schedules.

The biggest risk is not a missing test. It is a suite that passes at both levels while the thing it ran against no longer matches production: a mock written against last quarter’s API, a staging environment three deploys behind, a dependency that changed its response shape on Tuesday. Coding agents make this worse by volume. CircleCI’s 2026 report found engineering throughput up 59 percent year over year while roughly 30 percent of merge attempts fail, which means more changes reaching the seams between services and fewer of them verified there first.

This guide covers what microservices testing is, how the testing pyramid changes for services, and how to test at each stage from a laptop to production. It then looks at what is different about integration testing across dozens of services, what coding agents change, whether you still need a staging environment, and how to build and run a strategy that fits your team. The closing section explains how lightweight ephemeral environments on a shared cluster keep tests running against current dependencies without a full copy of the system per change.

What is microservices testing, and what is it for?

Microservices testing validates two things: the behavior of an individual service in isolation, and the behavior of the system when services interact. Unit and component tests cover the first. Contract, integration, and end-to-end tests cover the second. People also call it testing microservices, microservice testing, or distributed systems testing, and the practice is the same under each name.

It is for catching three classes of problem before users do: logic bugs inside a service, contract breaks between services, and behavior that only appears when real services run together under real conditions. It is not a substitute for observability in production, and it is not a way to prove a system correct. It narrows the gap between what a test checked and what will run.

In a monolith, most of the second category does not exist. A function calling another function shares a process, a compiler, and a deploy, so a changed signature breaks the build.

In a microservices architecture, the same call crosses a network to a service that may be on a different version, written in a different language, and owned by a team you have never met. Nothing breaks at build time. It breaks at runtime, in whichever environment first runs the two versions together.

That shifts where the effort goes. Testing a monolith is mostly about coverage of logic. Testing microservices is mostly about coverage of interactions: which services call which, with what payloads, and under what failure conditions. It is also about whether the version of each service you tested against is the version that will be running when your change ships.

Kubernetes made this the default problem rather than a niche one. The CNCF’s 2025 annual survey, published in January 2026, found that 82 percent of container users now run Kubernetes in production. Most of those systems are built from services that talk to each other, and every one of them needs an answer to the question this guide is about.

The testing pyramid for microservices

The microservices testing pyramid has five layers rather than the classic three: unit, contract, integration, end to end, and production validation. The two extra layers exist because two new failure modes appear between “the unit works” and “the whole system works”. A service’s API can drift from what its callers expect, and a release can behave differently under real traffic than under any test traffic.

Layer	What it checks	What it runs against	What it misses	Typical tools
Unit	A single function or class in isolation, with no network calls	Nothing external, only in-process fakes	Whether two services still agree on how to talk to each other	JUnit, pytest, Go testing, Jest
Contract	That a service's API still matches what its consumers expect: request shapes, response fields, status codes	A recorded specification of the other service, not the running service	How the service behaves under real conditions, past the shape of its responses	Pact, Specmatic
Integration	Real calls between services at the versions deployed	Live dependencies at their current versions, most reliably on a shared cluster with request routing	Full user journeys spanning the interface and every downstream service at once	Testkube, language test frameworks, Signadot Sandboxes
End to end	A complete user journey across every service it touches, treating the system as a black box	A fully deployed system	Little, but slowly and expensively, and a failure rarely says which service caused it	Cypress, Playwright, Selenium
Production validation	That a release behaves correctly under real traffic	Production, on a slice of real users	Nothing, but it finds problems after users have already met them	Canary deploys, feature flags, synthetic checks

Two things follow from the table. First, the layers are not interchangeable. A thousand unit tests say nothing about whether the orders service still returns the field the checkout service reads, and a passing contract test says nothing about what happens when the real orders service is slow.

Second, the integration layer carries more weight for microservices than the pyramid’s shape suggests. Interactions are where distributed systems fail, so the layer that tests interactions against real services is the one that catches the most expensive bugs. Keeping that layer current is the hard part, because an integration test is only as good as the dependencies it runs against.

Contract testing vs integration testing for microservices

A contract test checks that a service’s API still matches what its consumers expect, without running the other service. An integration test runs the real services together and checks what they do, which is the only way to catch behavior: a slow response, a wrong value in a correctly shaped field, a retry that double-charges. Teams that treat them as alternatives end up with one blind spot or the other. The complete guide to contract testing covers that distinction, the two contract models, and the tool landscape in full.

How to test microservices step by step

You test microservices in four stages: unit and local integration checks while the code is in the editor, integration tests against live dependencies at the pull request, end-to-end tests before release, and validation under real traffic in production. Each stage catches a different class of problem, and each one depends on the stage before it having done its job.

1. Local development: test the one service you changed against real neighbors

Start with unit tests for the logic you touched. They run in seconds, need no infrastructure, and should be the first thing that fails when you break something.

The harder question at this stage is what to do about dependencies. Running fifty services on a laptop stops working past a handful of services, and Docker Compose files that try to recreate the system fall out of date as fast as the system changes. The alternative is to run only the service you are changing locally and connect it to a shared Kubernetes cluster that already runs the stable shared version of everything else.

Telepresence and mirrord do this by intercepting traffic between your local process and the cluster. A lightweight ephemeral environment on the cluster does it by tagging your test requests so the cluster sends them to your local service and everything else to the stable copies. The local development on Kubernetes guide compares the options in detail.

Whatever the mechanism, the goal at this stage is the same: find integration problems while the code is still in your editor, when the fix costs minutes rather than a CI round trip.

2. Pull request and CI: run integration tests against current dependencies before merge

Once a change is in a pull request, CI should run the unit suite and then the integration tests for the services the change touches. The second part is where most pipelines fall short. CI runners start in a clean environment with no dependencies. Teams either mock everything, which loses the point of an integration test, or defer integration testing to staging, which moves the feedback to the slowest and most contended point in the pipeline.

The fix is to give each pull request an isolated place to run against live dependencies. A Kubernetes sandbox deploys only the changed services alongside a shared cluster and routes test traffic through them, while every other call falls through to the stable shared versions. Integration tests run against real services at their current versions, in parallel across every open pull request, without one environment per pull request.

This is also where contract tests belong if you use them. A contract test checks that your service’s API still matches what its consumers expect, and it can run in CI without any dependency being live. It catches a narrower class of bug than an integration test, but it catches it earlier and cheaper.

3. How to test microservices end to end before release

End to end testing microservices means treating the system as a black box and driving a complete user journey through every service it touches, usually from the UI with Playwright or Cypress. They are slow, they are brittle when the system changes, and a failure rarely says which service caused it. Keep this layer thin and reserve it for the journeys that matter most commercially.

The question is where to run them. The traditional answer is a staging environment: one deployed copy of the whole system that every team’s changes pass through before production. Staging works until the number of teams sharing it turns it into a queue, and until the effort of keeping it in sync with production lets it drift. Once it drifts, a passing staging run stops meaning much.

The alternative is an ephemeral environment per change, and there are two ways to build one. A full-stack ephemeral environment copies every service for every pull request, which removes the queue but multiplies the cost and gives each copy its own chance to drift. A lightweight ephemeral environment deploys only the changed services onto a shared cluster and routes everything else to the stable copies already running there, so every change gets an isolated slice of one current environment.

Whichever you choose, environment parity with production is the property to protect.

Performance and load tests belong at this stage too, and for microservices they belong before merge rather than in a separate performance environment after it. A load test with k6 against the changed service, running in the same isolated environment as the integration tests, catches the regression that only appears under concurrency while the change is still cheap to fix. Keep the suite small and the thresholds explicit, and treat a failure as a blocker rather than a note for later.

4. Production: validate under real traffic and limit the blast radius

Some behaviors only appear under production traffic: real data shapes, real concurrency, real third-party latency. Production validation is the top of the pyramid because it is the only layer that sees them.

Canary deployments route a small slice of traffic to the new version and compare error rates and latency against the current version before widening. Feature flags separate deploying code from enabling it, so a change can ship dark and be turned on for one percent of users. Synthetic checks run scripted journeys against production on a schedule so a regression surfaces before a user reports it.

None of these replace the earlier layers. They are the safety net for what the earlier layers could not see, and a team that leans on them to catch integration bugs is paying for those bugs in production incidents. Feature flags versus preview environments goes deeper on where flags help and where they hide problems.

Testing in microservices architectures: what is different

Testing in microservices architectures differs from monolith testing because correctness lives in the interactions between independently deployed services rather than inside any one of them. Even a small system makes the point.

Five things change when the codebase is thirty services instead of one.

• Failures happen at the seams. In a monolith, a bug is usually inside a function. In microservices, the bug is usually in the contract between two services: a renamed field, a changed default, a timeout that one side expects and the other does not honor. Neither service’s own tests can see it, because each service is correct by its own definition.
• Every service is on a different version. Services deploy independently, so at any moment the system is running a mix of versions nobody tested together. A test that pins its dependencies to specific versions is testing a combination that may never exist in production.
• The network is part of the system. Calls can be slow, can fail partway through, can be retried and arrive twice. Unit tests do not exercise any of this. Integration tests only exercise it if the dependency on the other end is real.
• Data is split. Each service owns its data, so a workflow that spans services spans databases. Tests that need consistent data across services need either a shared fixture every service agrees on, or a way to give a test its own isolated data without copying every database.
• Async flows have no call stack. When services communicate through Kafka or a queue, a producer’s test cannot see what a consumer did with the message. Testing the flow end to end means following a message through a broker, which most test frameworks were not built to do. Message isolation for Kafka and SQS covers how to test those flows without a broker per change.

The common thread is that correctness moved out of any one service and into the relationships between them. That is why the environment a test runs against, and how current its dependencies are, matters more for microservices than for anything that came before.

What AI coding agents change about testing microservices

Coding agents change microservices testing in two ways: they multiply the number of changes that need verifying, and they need that verification to happen without a person in the loop. Testing AI-generated code in a microservices architecture is the same problem as testing any other change, run at a volume and cadence the old pipeline was not built for.

The volume is measurable. GitHub’s own account of its August 2026 outage puts merged pull requests at about 130 million a month, well over double the monthly rate it reported for 2025, and Claude Code, Cursor, Codex, and GitHub Copilot all open pull requests on their own now. None of that volume removes a bottleneck that already existed in microservices testing. It multiplies the changes arriving at each one, and every one of those pull requests touches services whose neighbors it cannot see.

Agents are also consumers of the test environment, not only producers of changes. An agent works in a build-test-fix loop: write the change, run it against its dependencies, read the failure, fix, repeat. That loop cannot wait for a shared staging slot or a fifteen-minute environment build. An agent without a fast integration environment falls back to unit tests and mocks, which is exactly the layer that cannot see the seams.

Verification has to happen before human review, not after. A reviewer’s time is the scarce resource once agents generate the code, so the integration and end-to-end tests that used to run after approval need to run before the pull request reaches a person. The pull request arrives with evidence that the change worked against real dependencies, or it does not arrive at all.

Each agent run needs its own isolation. Two agents testing conflicting changes to the same service on one shared environment corrupt each other’s results, so every run needs an isolated slice of the dependency graph, created and destroyed on the agent’s timeline. That also means cost and lifetime controls: a time-to-live on every environment, and a cost model that scales with changed services rather than with the number of agents running.

An agent reaches the environment through the same interfaces a developer uses. It can run the CLI, call the API, or use a Model Context Protocol (MCP) server that exposes environment creation and test execution as tools it invokes directly, and which of the three it uses depends on where the agent runs. Validating AI-generated code against real Kubernetes dependencies covers that path end to end, including how an agent reads a failed integration run and iterates on it.

Do you need a staging environment to test microservices at all?

No, but you need what staging was for: a place where a change meets the current versions of everything it depends on before users do. The “staging is dead” argument is right that one shared copy of the system stops working past a few teams, and wrong when it concludes that mocks, contracts, and canaries can replace the integration layer entirely.

Staging is still the right answer for small systems. Under about ten services with one or two teams, conflicts are rare, drift is visible because everyone can see the whole system, and the cost of one shared copy is trivial. Replacing it with per-change environments at that size adds machinery without removing a problem.

Past that size, the shared copy becomes a queue and its drift becomes invisible, and the answer is to keep the property and change the mechanism. Every change still needs to run against live dependencies at current versions. What changes is that each one gets an isolated slice of a shared, current environment rather than a turn on the one copy. Kubernetes staging environments covers how teams make that move without a flag day.

Integration testing for microservices

Integration testing checks that two or more real services behave correctly when they call each other. Microservices integration testing is the layer that catches the seam failures described above, and the layer where the choice of what to test against makes or breaks the result.

Mocks versus live dependencies

A mock stands in for a dependency and returns canned responses. Mocks are fast, deterministic, and free of infrastructure, which is why WireMock and MockServer are on most teams’ shortlists. They are the right tool for unit and component tests, and for third-party APIs you cannot call from a test at all, which mocking third-party APIs inside a sandbox covers.

They are the wrong tool for verifying integration between your own services, for a reason that has nothing to do with the mocking library. A mock encodes what one team believed the other team’s API did on the day the mock was written. The other team keeps shipping. Nothing in the pipeline updates the mock, and nothing fails when the mock and the real service diverge.

The tests keep passing against a version of the dependency that no longer exists, and the first environment to run the real pair is the one that breaks. Integration tests pass with mocks but staging still breaks walks through this failure in detail.

Contract tests narrow the gap without closing it

Contract testing for microservices is the disciplined middle ground. The consumer publishes what it expects from the provider, the provider verifies it can meet those expectations, and a broker tracks which versions are compatible. Contract tests catch breaking API changes before merge and run without a live dependency.

What they do not catch is behavior. A provider can satisfy every contract and still return the wrong data, time out under load, or fail on the third retry. Contract tests verify the shape of the conversation.

Integration tests against the live service verify the conversation itself. Most teams that get this right run both, and the guide to AI-powered contract testing covers how the contract layer is changing as agents write more of the code on both sides of an API.

Where the live dependencies come from

If integration tests need live dependencies at current versions, something has to provide them. There are three models, and they differ in cost, in how far they drift, and in what they require of your services.

Model	How it supplies live dependencies	Where it breaks	Prerequisites	Best fit
Shared staging environment	One deployed copy of every service that all teams test against	Becomes a queue past a few teams, and drifts from production once keeping it in sync is nobody's job	A CD pipeline that deploys to it	Under ten services with one or two teams
Full-stack ephemeral environment per change	A fresh copy of every service for every pull request	Each copy costs as much as staging, takes as long to build as the whole system, and starts drifting the moment it is created	Namespace or cluster automation, seeded data per copy, budget that scales with pull requests	Small systems, or changes that touch most services at once
Lightweight ephemeral environment on a shared cluster	Deploys only the changed services and routes everything else to the stable shared copies already running	Needs a routing header propagated through every service, and stateful side effects isolated deliberately	Header or trace-context propagation across services, a proxy or service mesh	Ten or more services, multiple teams, or coding agents opening pull requests

The third model is the one most teams past a certain size land on. It is the only one whose environment stays current on its own. There is one shared set of stable dependencies, the CD pipeline already keeps it current, and every change gets its own isolated slice of it.

The prerequisite is real, though. If a service drops the routing header on the way through, requests behind it fall back to the stable copies silently, and the test passes against the wrong version without saying so.

Building a microservices testing strategy

A microservices testing strategy is the decision about how much to invest at each layer of the pyramid and where the integration layer gets its live dependencies. Three questions settle it for most teams, and one principle organizes the answer.

How many services, and how many teams own them?

Below about ten services with one or two teams, a shared staging environment and a thin end-to-end suite usually work. Conflicts are rare and drift is manageable because everyone can see the whole system.

Past that, staging becomes a queue and the drift becomes invisible, because no one team owns the whole picture any more. This is the point where integration testing needs an isolated place to run per change, and where the choice between copying environments and sharing one becomes the central architecture decision in the strategy.

Where do failures come from?

Pull the last quarter’s production incidents and sort them: bugs inside a single service, failures at the seam between two services, and configuration or environment differences. Teams that do this usually find the second and third categories dominate while their test investment is still weighted toward the first.

If that is your result, shift effort up the pyramid: fewer redundant unit tests and more integration tests against live dependencies. Add a hard rule that every pull request runs its integration tests before merge rather than after.

How fast is the change rate growing?

A pipeline sized for today’s pull request volume will be undersized within a year for most teams, and within months for teams adopting coding agents. Design for the volume you expect, not the volume you have.

The cost model decides whether that is affordable. A full-stack environment per change scales cost with the number of pull requests. A lightweight ephemeral environment on a shared cluster scales cost with the number of changed services per pull request, which is usually one or two regardless of how many pull requests are open.

Shift-left testing for microservices

Shift-left testing means running each layer of the pyramid at the earliest stage that can support it: unit tests in the editor, integration tests at the pull request, end-to-end tests before release rather than after. For microservices the shift that pays most is moving integration tests from staging to the pull request, because that is where seam failures are cheapest to fix and where a queue of changes waiting on one environment forms first. The shift-left testing guide for Kubernetes works through the mechanics stage by stage.

How do you know the strategy is working?

Measure it with the four DORA metrics: lead time for changes, deployment frequency, change failure rate, and time to restore. A testing strategy that moves integration tests to the pull request should show up as shorter lead time and a lower change failure rate within a quarter, because the seam failures that used to surface in staging or production now surface before merge.

If change failure rate does not move, the tests are still running against the wrong dependencies. If lead time does not move, the environment is still a queue. How to do DORA metrics right covers how to instrument the four without gaming them.

Match tools to layers

Most teams end up combining tools, one or two per layer. The survey of microservices testing tools for Kubernetes compares the field in depth. In brief:

• Unit and component: the language’s own test framework, with WireMock or MockServer standing in for HTTP dependencies.
• Contract: Pact, the open source framework, with SmartBear’s PactFlow as the hosted broker, or Specmatic for teams that want to drive contracts from OpenAPI specs. Signadot versus Pact covers where contract tests stop and live integration tests start.
• Local development against a cluster: Telepresence, now part of Ambassador’s Blackbird platform after Ambassador’s acquisition by Gravitee in 2025, with the open source project still under the CNCF. And mirrord from MetalBear, which began as a way to run a local process against cluster traffic and has grown cluster-side features since. Its Teams tier adds queue splitting for Kafka and SQS and database branching, and its Enterprise tier adds preview environments and CI use. Signadot versus mirrord compares the two models. So does Signadot versus Telepresence.
• Test orchestration in Kubernetes: Testkube runs existing Postman, k6, Playwright, and JUnit suites as jobs inside the cluster.
• End to end: Playwright or Cypress from the UI, k6 for load.
• Integration and end to end against live dependencies at current versions: a lightweight ephemeral environment per change, covered in the closing section.

No tool on this list solves the environment problem on its own. Something still has to give every change a place to run against dependencies that are current, and that decision shapes which of the other tools you need.

Running the shared test environment like a product

Whichever model supplies your live dependencies, the shared environment behind it needs an owner, a definition of current, and a way to tell whose change broke what. Teams that skip this end up with the drift they were trying to escape, one layer down.

Ownership comes first. The shared set of stable dependencies is a platform team’s product, with a stated objective for how far behind the main branch it may fall and an alert when it does. Parity is a mechanism, not a wish: the same CD pipeline that deploys production deploys the shared environment, from the same images and configuration, so the two cannot diverge by hand.

Data needs tiers. Shared read-mostly reference data can live once. Anything a test writes needs its own isolated schema or database per change, or tests corrupt each other and the shared copy. A change that alters a schema needs more than its own rows: it needs its own copy of the database, created from the shared one when the environment starts and discarded with it, so a migration under test can never reach the copy every other change depends on.

Async flows need the same isolation on the broker. A change’s messages reach only that change’s consumers, and a consumer under test reads only its own change’s messages, or a test on the orders service ends up processing another team’s events and both results are noise.

Access decides whether the environment gets used. QA, product owners, and reviewers need a URL per change. Developers need to connect a local process into the shared environment from their editor. Agents need the same through a CLI or MCP, with a time-to-live on everything they create.

When a test fails against forty real services, tracing has to attribute the failure to the one service that changed, or every failure becomes an investigation.

Microservices testing best practices checklist

Twelve yes-or-no questions. A team that can answer yes to all of them has closed the gap this guide is about.

1. Does every service have fast unit tests that run in the editor and in CI?
2. Do contract tests run before merge for every API another team consumes?
3. Does every pull request run integration tests against live dependencies before a human reviews it?
4. Are those dependencies at their current versions, kept in sync by the same pipeline that deploys production?
5. Can two changes to the same service be tested at the same time without interfering?
6. Does each change that writes data get its own isolated schema or database?
7. Do async flows through Kafka or a queue get the same isolation as synchronous calls?
8. Can a developer connect a local process to the shared environment instead of running the system locally?
9. Can a coding agent create, test against, and destroy an environment without a person in the loop?
10. Does every environment a change creates carry a time-to-live?
11. When an integration test fails, does tracing point at the one service that changed?
12. Is your end-to-end suite thin enough that a failure is investigated the same day?

How lightweight ephemeral environments keep every test running against current dependencies

A lightweight ephemeral environment keeps tests current by giving every change its own isolated copy of only the services it touched, running against the stable shared versions of everything else, so integration and end-to-end tests always meet current dependencies. Signadot’s Sandboxes are a mature implementation of this pattern, and the microservices testing solution overview covers how teams adopt it.

The mechanism, in plain words: fork only the services that changed, route everything else to the shared running copies, isolate stateful side effects, and manage the lifecycle through a CLI, an API, or MCP. One Kubernetes cluster runs the stable shared version of every service, kept current by the same CD pipeline that deploys production. When a change needs testing, a Sandbox deploys only the changed services alongside them and expires on a timer once the change merges or is abandoned.

Test requests carry a routing key in a header. A service mesh or lightweight sidecar reads that key and sends the request to the forked service, while every other call falls through to the stable copy. The same key travels through message queues for async flows, and a Sandbox that touches data can carry its own isolated database or schema so its writes never reach the shared copies.

An integration test for a two-line change therefore runs against every other service at its current version without deploying those other services. Spin-up takes seconds because only the changed service is deployed, and cost scales with changed services rather than total services. Drift stops being a problem because there is one environment, and the CD pipeline already keeps it current.

That is the property the rest of this guide has been circling. When every test runs against dependencies that are current, the distance between a passing test suite and a working production system gets small enough to trust. It stays that small as the number of services and the number of authors keep growing.

Where to go next

If you run fewer than ten services and staging still works, read the staging environments guide and keep it healthy. If staging has become a queue, start with the ephemeral environments guide and the comparison of environment architectures above. If agents are opening your pull requests, start with validating AI-generated code against real Kubernetes dependencies, because the pipeline you build for them is the pipeline everyone else ends up using.

Related Articles

• Local Development on Kubernetes: The Complete Guide
• Best Microservices Testing Solutions for Kubernetes
• The Future of API Validation: A Deep Dive into AI-Powered Contract Testing
• What Is a Kubernetes Sandbox?
• Microservices Testing for FinTech
• Integration tests pass with mocks but staging still breaks: how to catch it earlier
• Guide to Shift-left Test Approach in Kubernetes
• Testing Microservices: Message Isolation for Kafka, SQS, More
• Why Scaling Makes Microservices Testing Exponentially Harder

Frequently asked questions

What is the difference between microservices testing and integration testing?

Integration testing is one layer inside microservices testing, not a separate practice. Microservices testing covers unit, contract, integration, and end-to-end tests together, while integration testing microservices means checking specifically that two or more real services behave correctly when they call each other. Contract testing sits between the two, checking that a service's API still matches what its consumers expect without running the full integration.

How do you test microservices locally?

Run only the service you are changing on your own machine and connect it to a shared Kubernetes cluster that already runs the stable versions of everything else. A lightweight ephemeral environment on that cluster tags your test requests so they reach your local service while every other call goes to the shared copies. Local microservices testing then covers real dependencies without running fifty services on a laptop.

What is the microservices testing pyramid?

The microservices testing pyramid stacks five layers by test volume and speed. Unit tests form the wide base, fast and numerous. Contract tests check that a service's API matches what its consumers expect. Integration tests verify real service-to-service behavior, which is where microservices break most often. End-to-end tests check complete user journeys, and production validation confirms a release under real traffic.

Is a staging environment required for testing microservices?

No. What microservices testing needs is a place where a change meets the current versions of its dependencies, and a shared staging environment is only one way to get that. A lightweight ephemeral environment per change on a shared cluster gives the same dependency fidelity without a queue for one shared copy, and without the cost of duplicating the whole system for every pull request.

How does contract testing fit into a microservices testing strategy?

Contract testing sits between the unit and integration layers of a microservices testing strategy. It checks before merge that a service's API still matches what its consumers expect, catching breaking changes that unit tests miss and that a full integration test catches too late to be cheap. Most teams pair it with integration tests against live dependencies, because a contract verifies the shape of a response, not the behavior behind it.

Why do microservices tests pass but production still breaks?

Because the tests ran against dependencies that no longer match what runs in production. Mocks go stale as the services they imitate change, and a staging environment three deploys behind gives the same false confidence. The fix in microservices testing is to run integration tests against the current shared versions of dependencies rather than against static mocks or a copy of the system that has drifted.

How many environments do you need to test microservices safely?

Three layers, not a separate dev, QA, staging, and pre-production environment apiece. You need a local or agent working copy of the one service being changed, one shared cluster holding the stable versions of every other service, and a way to give each change its own isolated slice of that cluster. That is enough for microservices testing at any number of services, because one cluster serves every change at once.

Can a coding agent test its change against real dependencies before opening a pull request?

Yes, if it has somewhere to run the test. An agent works in a build-test-fix loop and needs an isolated environment with real dependencies it can create, test against, and tear down without waiting on a person. Given a CLI, an API, or an MCP server that exposes those actions, agents like Claude Code and Cursor run microservices testing before a reviewer ever sees the change.

How do AI coding agents change microservices testing requirements?

They raise the volume of changes and remove the person from the loop. Every agent run needs its own isolated environment with live dependencies, a time-to-live so abandoned runs clean themselves up, and integration results attached to the pull request before human review. Microservices testing for agent-written code is the same set of layers as before, run per change at a cadence a shared staging environment cannot keep up with.

What is the difference between a microservices test environment and a Sandbox?

A test environment is the general category: any place a change runs against its dependencies, from a shared staging cluster to a full copy per pull request. A Sandbox is Signadot's lightweight ephemeral environment, which deploys only the changed services onto a shared cluster and routes the rest of the traffic to the stable copies. In microservices testing terms, it is one way to build a test environment, not a different kind of thing.