Mocking vs. Integration Testing: Why Not Both?

Tom Akehurst

CTO and Co-founder

September 5, 2025

Table of Contents

This is some text inside of a div block.

Do you test with mocks or run full integration tests? As with many arguments about developer tools and practices, it’s easy to choose sides and get into heated debates defending them. However, we’re increasingly finding that it’s less a binary choice, and more of a spectrum - where efficient testing requires you to mix-and-match your approach to simulation vs. integration.

The Problem With Mock First, Integrate Later

In the past, we wrote unit tests with mocks for fast feedback - then deployed to a full replica

of production for end-to-end validation. Isolated testing first, comprehensive integration second.

This worked when systems were simpler. When you had a few services, maybe a database, and predictable dependencies. The cost of running a full environment was manageable, and the complexity didn't spiral out of control.

Then microservices happened. And cloud. And partner APIs. And legacy systems that refuse to die.

Suddenly, your "simple" integration test environment needs dozens of services and external dependencies that may or may not be available. The full integration approach becomes expensive to maintain, slow to execute, and hard to trust - with flaky tests frequently blocking deployments (and annoying developers).

But simple mocking isn't the full answer either. Mocks don't catch integration issues. They don't reveal when your service contract assumptions are wrong, or when that third-party API changes in ways you didn't expect.

Hybrid Approaches

What we’re seeing much more of lately is teams choosing a middle path – selectively mixing real and simulated components. Instead of all-or-nothing, they're choosing what-makes-sense.

Service cluster testing: Teams test tightly coupled services together while simulating everything outside their domain. A checkout flow might test the cart, inventory, and order services as a unit while simulating payment gateways and shipping providers.

Layer-based simulation: New microservice layers integrate against real infrastructure but simulate legacy systems. This validates the new architecture without the overhead of provisioning systems that take days to set up.

‍Ownership boundaries: Test services you control against real implementations while simulating third-party and partner APIs. You get confidence where you have both responsibility and capability to fix issues.

This approach maximizes useful insights into integration risk while maintaining velocity. You get real confidence where it matters most, without the overhead of running everything.

What Makes This Possible?

Mixing real and simulated services isn't trivial. There are two major technical hurdles you need to solve for, which most mocking frameworks don’t give you much help with:

Data consistency becomes critical when services reference each other's data. If your user service is real but your order service is simulated, they need shared customer records or you'll get broken references and false failures.

State management gets complex fast. A single integration test might trigger orchestrated operations across multiple services. Your simulations need to model state changes accurately, or the entire orchestration fails in ways that don't reflect real production behavior.

Without veering too far into self-promotion, we’ll note that this is why we’ve added these capabilities in WireMock Cloud, and why today we mostly refer to what we do today as “API simulation” rather than API mocking.

A simulation should be able to replicate the behavior of a real API, not just in terms of canned response patterns, but in terms of its behaviour as part of a distributed system. State management, fault injection, data sources - these are all things we’ve added to our own platform in recent years, often following conversations with customers; and it’s why today WireMock Cloud is being used in complex, integration-heavy environments, rather than a multitude of basic and basically-free alternatives available.