Bad ideas in software spread like a virus, quietly multiplying until they inflate costs and manifest as technical debt. One such idea is the misguided faith in integration tests to catch bugs and ensure delivery confidence. In this article, I’ll break down why integration testing is not just inefficient but actively harmful to your delivery process. I’ll also explore how unit testing provides a faster, more reliable path to achieving high-quality software.

The Integration Tests

Unit tests form the foundation of our coding process, offering quick, focused validation of individual components. In a monolith, testing interactions between different parts is relatively straightforward. But the real challenge emerges in systems like microservices, where teams, artifacts, and deployments are independent. Integration tests might seem like the solution—a way to verify that independently developed parts of the system work together as intended [1].

That sounds logic, and to some extent, it is. Integration tests aren’t inherently bad; the issue lies in their misuse. The real problem arises when they’re applied indiscriminately across the codebase. Martin Fowler highlights the distinction between narrow and broad integration tests. The terms are self-explanatory [1]:

narrow integration tests

• exercise only that portion of the code in my service that talks to a separate service
• uses test doubles of those services, either in process or remote
• thus consist of many narrowly scoped tests, often no larger in scope than a unit test (and usually run with the same test framework that’s used for unit tests)

broad integration tests

• require live versions of all services, requiring substantial test environment and network access
• exercise code paths through all services, not just code responsible for interactions.

From that definition, we can infer that broader tests introduce more complexity, while narrower tests offer a simpler, more effective approach. But let’s revisit this later. First, let’s examine a case involving an application with time-sensitive and stochastic behavior [2].

Can you break both time and randomness for testing? At some expense they can be surmounted. However, this requires significant resources and a demanding setup process. Is the effort justified? Let’s break it down. Spoiler alert: it is not!

Combinatorics and Algorithmic Complexity

Let’s analyze the complexity of some systems using their cyclomatic complexity as a reference [3].

Basic math suggests that for three systems, A, B, and C, we’d need at least

$$ 5 \times 3 \times 4 = 60 $$

test cases to cover the happy paths. But is that truly enough? Unfortunately, no. This calculation only accounts for direct interactions between A, B, and C. In reality, additional factors come into play:

1. Conditional Interactions: Certain paths depend on specific conditions in other systems (e.g., A influencing B’s path choices).
2. Shared State: Systems sharing data or states introduce dependencies that multiply complexity.
3. Control Flow Complexity: Features like loops, recursion, or dynamic calls between systems exponentially increase the number of potential paths.

We also need to consider edge cases, such as when systems fail or throw exceptions (e.g., no connection to the database). These scenarios can’t be ignored but add further complexity.

So, while $60$ cases might seem like a reasonable estimate, this number is conservative. We can safely state that at least this case would yield

$$ A \times B \times C \approx +60 $$

Now, imagine adding another system, D, with a cyclomatic complexity of 2.

With D in the mix, the number of scenarios doubles to $120$. This isn’t even exponential growth $O(2^n)$—it’s factorial behavior $O(n!)$. Exponential is Factorial’s morning coffee! As more systems are added, the testing effort quickly spirals out of control, making comprehensive integration testing impractical.

Let’s depict them to see the difference. Let’s define them as $f = 2^n$, whereas $g = n!$ [4].

The Vicious Circle

What’s the issue with spreading integration tests across the codebase? It’s a vicious cycle—a negative feedback loop that signals deep flaws in the software architecture design.

Unit tests exist to isolate and stress individual components, ensuring they perform as intended. When writing these tests (especially in a TDD workflow) becomes difficult, it’s a clear indicator of architectural problems. If our architecture forces us to struggle with TDD or write excessive setup code—say, 30 lines before testing—it’s a sign we rely too heavily on external dependencies. The tests, in this case, are offering valuable feedback: our design needs serious improvements.

Now, consider what happens when we handle mistakes (not bugs, as we introduced those) by writing integration tests instead of refining the architecture. These tests fail to adequately stress the system, leading to sloppy designs. To compensate, we write even more integration tests, neglecting unit tests and allowing mistakes to pile up. The result? We create an illusion of confidence with 100% passing integration tests, while the system’s design remains flawed—a loop doomed to repeat itself [3].

The danger of broad integration testing lies in its inability to provide meaningful feedback on design. The more integration we attempt to cover, the less insight we gain into the system’s structural health. Instead of addressing the root issue, we settle for shallow tests that mask the cracks, fostering careless designs and leaving potential problems unresolved.

What to do then?

Contract Testing

Test Doubles

It’s time to start connecting the dots. While everything might seem scattered, the pieces align with a clear logic. Previously, I wrote:

This isn’t to say that mocking tools are inherently bad. They can be incredibly useful in specific scenarios, such as working with legacy code. However, over-reliance on mocking often results in superficial testing, brittle code, and fragile tests that obstruct long-term maintenance and improvement. Mocking should be a tool in your arsenal, not the foundation of your testing strategy [5].

This remains true: mocking isn’t inherently bad—it just needs to be used wisely as part of a broader testing strategy.

One scenario where Test Doubles (mocking, as we’ll call it moving forward) makes perfect sense is in communicating with external services. These are often maintained by other teams and accessed through slow or unreliable communication channels. In such cases, mocking becomes an essential tool to simulate these interactions efficiently, faster, and reliably within your tests [6].

Mocks are defined by their primary characteristic: they are pre-programmed with specific expectations, establishing a clear contract for the interactions they are designed to receive [7].

Interfaces (or just Contracts)

In broader terms, let’s talk about interfaces as they often been taught to think of:

A “protocol type […] that acts as an abstraction of a class. It describes a set of method signatures […]. A class which provides the methods listed in a protocol is said to adopt the protocol, or to implement the interface.” [8]

What does this really mean? Simply put, it’s a Contract! [9]

By the way, Merriam-Webster defines a contract as:

a binding agreement between two or more persons or parties.

In our context, interfaces represent contracts, and mocks embody expectations about those contracts. But who are the parties involved?

High Cohesion, Loose Coupling

On one side, we have the consumer, and on the other, the producer (or client-server-like relationship). Let’s illustrate this relationship and refine the depiction step by step to clarify their roles and interactions.

Let’s start connecting the dots. Interfaces aren’t just some dull rules sitting around—they hold value because their success depends on all parties fulfilling the contract. On the left side of the diagram, this means knowing what to ask for and how to interpret the response, without needing to understand the underlying implementation [3].

It’s like working with an array: you push a value, then call the length function. You don’t need to know how the length is calculated, but you know the result must be 1. Why? Because someone, somewhere, has fulfilled the contract.

On the consumer side (collaboration testing), testing is all about asking the right questions (mocking) and being prepared to handle every possible response (stubbing).

Let’s consider a scenario: fetch all my account transactions. Intuitively, we know we should be ready for:

• No transactions.
• One transaction.
• A few transactions.
• Many transactions (likely to have pagination).
• An error response (e.g., the connection to the database has failed).

Testing here isn’t about understanding the “how.” It’s about knowing the range of possible answers and ensuring the consumer reacts appropriately. The beauty of the contract is that it abstracts away the implementation—it guarantees that if you ask the right question, you’ll get a valid response. That’s why contracts matter!

Everything on the consumer side can be thoroughly tested and programmed, but it’s all for nothing if the producer fails to fulfill the contract (i.e., implement the interface). For this setup to work effectively, the producer must guarantee that every expectation posed by the consumer is met with an appropriate Action [3].

Similarly, for every expected response (stubs), the producer must ensure it can deliver those responses. This requires the producer’s tests (contract testing) to rigorously assert these scenarios, confirming that its implementation aligns perfectly with the contract’s requirements. Without this symmetry, the entire contract-based approach falls apart [3].

A Bit of (Mathematical?) Induction

We’ve now reached a point where both parties—the consumer and the producer—are (ideally) working seamlessly. To simplify their relationship, we can represent them as boxes, with the interface depicted as a connecting pipe.

When considering complex systems, we can observe that what works for one interaction can scale to many. Without delving into a formal proof by mathematical induction, this generalization allows us to visualize a complex system as a series of interconnected boxes, each linked through interfaces up to its boundary—the part of the system we control.

But what happens when we reach the very edge of the system boundary? How do we handle interactions with the external world, which lies outside our control? This is where implementing narrow integration tests becomes valuable.

The great outcome of this rework is how it transformed our testing strategy, achieving a more linear and predictable behavior, significantly reducing complexity, passing from a factorial behavior to a more linear-like behavior.

$$ \Pi_i p_i \Longrightarrow \Sigma_i p_i $$

Some Real Case Evidence

Does it pay off? I’m confident it does. Take NuBank’s case, for instance, and their decision to switch from integration tests to a contract test-based strategy. You can dive into their full blog entry at https://building.nubank.com.br/why-we-killed-our-end-to-end-test-suite/, but the key takeaways are the remarkable improvements they achieved:

1. Faster Feedback Loops: By eliminating reliance on slow integration tests, NuBank reduced their cycle time significantly, allowing developers to iterate and deploy faster.
2. Increased Deployment Frequency: They went from at most 100 deployments per week to nearly 1000, empowering teams to deliver value at a much higher rate.
3. Higher Confidence: Contract tests allowed them to simulate realistic interactions with external systems, ensuring correctness without the flakiness and unreliability of broad integration tests.
4. Reduced Maintenance Overhead: Removing complex E2E testing infrastructure reduced the effort and costs associated with maintaining test environments.
5. Improved System Design: Focusing on contracts between services highlighted areas where improvements in decoupling and design were needed, leading to a more resilient architecture.

NuBank’s experience shows that moving away from broad integration testing not only improves efficiency but also strengthens the overall system’s quality and maintainability.

Conclusions

1. Integration Testing Pitfalls: Over-reliance on integration tests leads to increased complexity, bloated test cases, and shallow feedback on system design, creating a vicious cycle of technical debt.
2. The Value of Unit Tests: Unit tests offer precise, fast feedback and stress isolated parts of the system, highlighting design flaws and encouraging better architecture.
3. Combinatorial Explosion: Broad integration testing becomes impractical as the system grows, with complexity escalating factorially, making comprehensive coverage unattainable.
4. Contract Testing as the Solution: Contracts define clear expectations between consumers and producers, enabling reliable and efficient testing while maintaining loose coupling and high cohesion.
5. Consumer-Producer Symmetry: Effective contract testing relies on both consumers and producers fulfilling their parts—consumers must ask the right questions and handle responses, while producers must meet expectations and guarantee valid responses.
6. Narrow Integration Testing: At the system’s external boundaries, narrow integration tests ensure proper interaction with external dependencies, avoiding the pitfalls of broad integration tests.
7. Real-World Evidence (NuBank):
   • Faster feedback loops for developers.
   • Increased deployment frequency (up to 10x improvement).
   • Higher confidence in system reliability.
   • Reduced test infrastructure maintenance costs.
   • Improved system design through better decoupling.
8. The Big Picture: By focusing on contracts and minimizing broad integration testing, teams can deliver faster, reduce waste, and build maintainable, scalable systems.

Bibliography

1. M. Fowler, Integration test, martinfowler.com, 2018. [Online]. Available: https://martinfowler.com/bliki/IntegrationTest.html
2. G. Hill, TDD: Resist integration tests, GeePawHill.org, 2018. [Online]. Available: https://www.geepawhill.org/2018/04/04/tdd-resist-integration-tests/
3. J. Rainsberger, Integrated tests are a scam, 2013. [Online]. Available: https://vimeo.com/80533536
4. M. Rendon, Algorithmic complexity, mesirendon.com, 2022. [Online]. Available: https://mesirendon.com/articles/algorithmic-complexity/
5. M. Rendon, Mocking mayhem: Cutting the strings on overengineering golang, mesirendon.com, 2024. [Online]. Available: https://mesirendon.com/articles/mocking-mayhem-cutting-the-strings-on-overengineering-golang/
6. M. Fowler, Contract test, martinfowler.com, 2011. [Online]. Available: https://martinfowler.com/bliki/ContractTest.html
7. M. Fowler, Test double, 2006. [Online]. Available: https://martinfowler.com/bliki/TestDouble.html
8. Wikipedia contributors, Interface (object-oriented programming), 2023. [Online]. Available: https://en.wikipedia.org/wiki/Interface_(object-oriented_programming)
9. M. Rendon, Go interfaces, mesirendon.com, 2024. [Online]. Available: https://mesirendon.com/articles/go-interfaces/#whats-a-go-interface