Testing with Real Services: A Pragmatic Guide to Integration Testing Without Mocks

Listen up, team. I'm Integra, and I'm here to tell you something that might ruffle some feathers: your mock-heavy test suite is giving you a false sense of security. Sure, mocks are fast, predictable, and easy to set up. But they're also lying to you about how your system actually behaves in production.

After years of watching "well-tested" applications crumble in production because their integration points were validated against fantasyland mocks, I've become a staunch advocate for real service testing. Not because I'm a purist, but because I'm pragmatic. I want tests that actually catch the bugs that matter.

In this guide, I'll walk you through the systematic approach to integration testing with real services—the kind that actually tells you if your database queries work, if your API calls succeed, and if your message queues deliver messages. We'll cover environment setup, credential management, cleanup strategies, and how to achieve that sweet spot of 90-95% coverage without burning down your CI/CD pipeline.

Why Real Services Beat Mocks (Most of the Time)

Let's address the elephant in the room first. The testing pyramid, introduced by Mike Cohn in 2009, has guided generations of developers toward a foundation of unit tests with fewer integration tests on top[^1]. And that's still sound advice. But here's where teams go wrong: they replace all integration testing with mocked dependencies, thinking they're being efficient.

The Problem with Mock-First Testing

When you mock your database, you're testing your mock, not your database. When you mock your HTTP client, you're validating that you called fetch() correctly, not that the remote API actually returns the data your code expects[^2].

Here's what mocks can't catch:

• Schema mismatches: Your mock returns user.firstName, but the API actually sends user.first_name
• Network failures: Timeouts, connection resets, DNS failures—all invisible in mock-land
• Database constraints: Your mock happily accepts duplicate emails, but PostgreSQL throws a unique constraint violation
• Authentication flows: OAuth tokens expire, refresh tokens fail, API keys get rate-limited
• Serialization issues: That JavaScript Date object doesn't serialize the way you think it does

As Philipp Hauer eloquently put it in his 2019 article: "Integration tests test all classes and layers together in the same way as in production. This makes bugs in the integration of classes much more likely to be detected and tests are more meaningful"[^3].

When Mocks ARE Appropriate

I'm not a zealot. There are legitimate scenarios for mocks even in integration testing:

1. Testing failure scenarios: Network simulators like Toxiproxy can inject latency and failures in controlled ways[^3]
2. Third-party services you don't control: If you're integrating with Stripe's production API, you probably want