When people talk about software testing, they often reach for a single “best practice.” Some teams pride themselves on unit test coverage. Others lean heavily on end-to-end tests. But just like with software delivery as a whole, the strongest results come from layers of testing — not perfection in one category.
Let’s walk through what those layers look like, what each one gives us, and how they fit together.
The Layers of Developer-Written Tests
There are lots of ways to slice tests, but here’s a practical set of categories I find useful:
- Unit tests – Fast, focused, run entirely in-memory.
- Service-scoped integration tests – Tests that exercise a running service, proving the business logic is wired up and that the service is actually reachable.
- Component integration tests – Still written like unit tests (directly invoking code), but deliberately touching real external dependencies instead of mocks.
- End-to-end cross-service tests – Longer running scenarios that cross multiple services, such as sagas or workflows.
Each layer adds something the others can’t quite give us.
What Each Layer Is Useful For
Unit tests
Unit tests aren’t just about catching logic errors. With test-driven development (TDD), they help shape the architecture of the code as we write it. They’re also fast and give us confidence while refactoring. The flip side is that because they evolve with the code, they’re not the most reliable regression safety net — refactoring tools can often update them automatically.
Service-scoped integration tests
These are fantastic for proving our service actually runs the way we think it does. They confirm that the business logic is wired up correctly, the database is reachable, the blob store responds, and the service isn’t just compiling — it’s alive. The trick is to keep the test scope tight: real platform dependencies like databases and blob stores, but imposters for other services. That way, when a test fails in the pipeline, the failure really belongs to our service, not something outside our control.
Component integration tests
This is where we directly exercise code paths that talk to externals — downstream services, APIs, or shared components. They’re especially powerful for things like consumer contract testing. I tend to push back on the common wisdom that contract tests should be unit tests. By verifying the real infra stack, we get much stronger guarantees: can we access the dependency at all? Does the call go through the real networking stack?
End-to-end cross-service tests
These are the slowest, the most brittle, and the easiest to overdo. Long-running sagas or workflows that span multiple services usually need their own pipelines — sometimes run on a schedule or triggered manually. They’re useful, but they have to be scoped carefully, or they end up producing noise instead of insight.
Why Not Just Pick One?
For many microservices, you can get away with just unit tests plus service-scoped integration tests. That’s often all you need. But sometimes the complexity of the domain demands more.
Take a search service that aggregates results from dozens of external third-party systems. You don’t control their data, their availability, or their quirks. Getting all of that to line up perfectly with your own data store is tricky. No single type of test is enough to give you confidence.
That’s where a layered approach comes in.
What a Layered Approach Looks Like
Imagine stacking your tests like filters, each catching a different type of problem:
- Unit tests verify the business logic, like combining results from multiple third-party services.
- Component tests hit each downstream dependency individually, probably just one per test, so you know the contracts actually hold.
- Component tests (with imposters for downstreams) pull all impostered calls together, to check that your data combination logic still works when real databases and blob stores are in play.
- High-level end-to-end tests make sure you’re not seeing unexpected failures in production-like flows.
The point isn’t to test everything at every layer. The point is to think about what each layer uniquely proves. If every test has only one reason to fail, then when it fails, you actually learn something.
Wrapping It Up
A layered approach to testing is less about writing more tests and more about writing useful tests. Each layer trims down a class of potential failures before they escape. You don’t need perfection at any one layer — just enough strength in each to build a solid wall of confidence.
So here’s the question to ask yourself:
👉 Looking at your service, are you leaning too hard on one layer while ignoring others? Or do you have enough bricks in the wall to stop most defects from slipping through?
That reflection is where real quality begins.
Coding Daddy Dobbs 