Microservices Testing
Microservices testing with real dependencies on every change.
Signadot gives every pull request, developer and coding agent an ephemeral environment on the Kubernetes cluster you already run. Your integration, end-to-end, performance and chaos tests run against real services, message queues, databases and workflows before code merges.
- No credit card required
- Runs on your existing cluster
Trusted by engineering teams worldwide
Why microservices testing breaks down at scale
The failures that reach production sit between services, and every common workaround either hides them or queues behind them. The complete guide to microservices testing covers every layer, from unit tests to production.
Mocks drift from the services they copy
A mock records what another team's API did on the day someone wrote it. The real service keeps changing, the mock does not, and the suite stays green until the two meet after merge.
One shared staging cluster turns into a queue
When every branch deploys to the same environment, a red test could belong to anyone. Engineers wait for a turn, then spend it working out whose change broke the run. The complete guide to staging environments covers why the queue forms and what replaces it.
Copying the whole stack costs too much
A namespace or cluster per pull request removes the queue, then multiplies the bill by the number of open branches and takes as long to start as the whole system.
Coding agents multiply the changes
Agents open pull requests faster than people can review them. If none of those changes met a real service first, the reviewer ends up doing the integration testing by reading diffs.
Agents can only validate what they can run.
Unit tests, types and lint need nothing but the code. Integration, end-to-end, performance, chaos and security tests need live services to call. Signadot supplies the services, and your tests do the checking.
How Signadot fits your microservices testing
Signadot is the environment layer. It gives each change a place that behaves like production, and leaves the tests, the runners and the reporting you already have where they are.
An ephemeral environment for every change
Signadot duplicates only what a change touched or needs to isolate, such as a service, a database or a queue, and links it to everything else through request routing, message routing and configuration changes. The changed service can run in the cluster or on a laptop, so local development, pull requests and agents test against the same real dependencies.
Your tests, run from wherever suits them
Point the suites you already have at the environment's URL or routing key. Run them from a laptop while the change is still in the editor, from a CI pipeline in GitHub Actions, GitLab or Jenkins, or as Signadot Jobs, which run a suite in pods inside the cluster next to the services it tests.
Coding agents test before they open a pull request
Agents create and delete environments through the Signadot CLI, the MCP server or agent skills, run the same suites against real services inside their own loop, and fix what fails. Every environment carries a time-to-live, so abandoned runs clean themselves up.
> test the refund change against real services
→ creating environment for orders@pr-425
✓ environment ready, routing key attached
✓ integration suite 24/24
⠋ e2e: refund journey, waiting on inventory eventSynchronous calls, async messages and durable workflows.
Microservices talk over REST and gRPC, through brokers and through workflow engines. A change's environment has to carry each kind of flow, or the tests stop at the first queue.
-
REST and gRPC calls
A routing key in the request headers sends calls to the changed service and lets every other call fall through to the shared version. Istio, the Gateway API or the DevMesh sidecar does the routing, and OpenTelemetry carries the key from hop to hop.
Context propagation -
Kafka, SQS, RabbitMQ, Pub/Sub
Producers carry the same key in message headers. Each consumer version takes only its own messages, so a change can publish and consume on the shared broker without touching anyone else's events.
Message isolation -
Temporal workflows
A changed worker polls the shared task queue next to the stable one and picks up only the workflows started with its key. The steps it runs call the real services around it.
Temporal tutorial -
Databases and other resources
Share the database with each test's rows kept apart, or give a schema change its own temporary database or Neon branch. Resource plugins create anything else a change needs, in the cluster or outside it.
Resource plugins
Test cycles cut from 60 to 10 minutes
Signadot is a key part of our solution for the most critical parts of our testing pyramid. For integration and end-to-end testing we need to have a sandbox up and running because they need a live service to talk to.
Integration and end-to-end tests need live services.
Earnest runs the critical layers of its testing pyramid against real services in an environment per change, and cut test cycles from 60 minutes to 10.
Customer results
Teams testing microservices on Signadot
$2M saved annually
On the margin, with the Signadot approach, 99.8% of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not.
Connor BraaSoftware Engineering Manager 
83% lower change failure rate
We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast.
Marcus TavaresStaff Software Engineer 
10x integration capacity
Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us several million dollars annually.
Jony JeyaratnamHead of Engineering 
82% lower change failure rate
Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test.
Naomi KleinLead Infrastructure Engineer Microservices testing, built for coding agents.
Claude Code, Cursor, Codex and Copilot write microservices changes faster than anyone can review them. Signadot gives each agent a real environment on your own cluster, and Plans let agents write the testing workflows they run in it.
A real environment inside the agent's loop
Each agent task gets its own environment in seconds, runs the suites against real services, and reads the failures in the same session it wrote the code.
Plans: testing workflows agents write
Agents author Plans in plain language from an action catalog your platform team governs, then run them by name through the MCP server or CLI until every check passes. How Plans work.
Pull requests that arrive tested
The change a reviewer opens has already run against real services, with results on the pull request, so review time goes to judgment instead of triage.
Microservices Testing FAQ
What should a microservices testing solution provide?
Somewhere real for every change to run. Teams already own their test frameworks, so the gap is an environment per pull request, developer and agent task that holds the current versions of the other services, its own state where a change needs it, and nothing another team is testing at the same moment. Signadot provides that environment layer on the Kubernetes cluster you already operate.
Is Signadot a test automation tool?
No. Signadot gives each change an ephemeral environment, and your tests decide whether the change works. Playwright, Cypress, Postman, k6, pytest or any other suite runs against it from CI, from an orchestrator such as Testkube, or from a pod in the cluster. For teams with nowhere else to run a suite, Signadot Jobs can start one in the cluster.
Which kinds of tests can run in a Signadot ephemeral environment?
Any test that needs live services to call. Teams run integration and end-to-end suites on every pull request, performance checks that compare the changed service with the shared version, fault-injection tests for timeouts and retries, and authorization tests between services. Unit tests, linting and contract checks keep running in CI as they do today, since they need no environment.
How are Kafka, SQS and RabbitMQ handled when several changes test at once?
The broker stays shared. A producer in the environment stamps each message with the change's routing key, and each consumer version takes only the messages addressed to it, so one change never eats another change's events. Signadot documents this pattern for Kafka, RabbitMQ, NATS, SQS with SNS and Google Pub/Sub. A change that needs a topic or queue to itself can get one from a resource plugin.
Can Signadot test changes to Temporal workflows?
Yes. The changed worker joins the same Temporal task queue as the stable worker, and workflows started with the change's routing key go to the new code while all other work stays on the current workers. Its activities then call real services, databases and queues. The Temporal tutorial in the Signadot docs shows the setup for Python, TypeScript, Go and Java workers.
How is this different from a namespace per pull request?
Cloning a namespace for each branch duplicates all of the services, so the bill climbs with every open pull request, startup waits on the slowest service, and the copy falls behind the moment it exists. A Signadot environment deploys only the services a change touched, plus any database or queue it must own, and links them to everything else already running. Hundreds of them fit on one cluster.
How do coding agents test microservices changes with Signadot?
Claude Code, Cursor, Codex, Copilot and similar agents call the Signadot CLI or MCP server to spin up an environment scoped to the task, point your integration and end-to-end suites at the real services, read what failed and try again. The environment expires on a timer, and the pull request reaches a reviewer with test results already attached.
What does it take to start?
Install the Signadot Operator in a Kubernetes cluster that already runs your services, then create environments from the CLI, from CI or through the MCP server. To try it before touching your own cluster, use the free Playground cluster, with no credit card required. Your code and data stay in your cluster.
Building a strategy first? Read the complete guide to microservices testing, from test types to synchronous, asynchronous and workflow flows.