Do we need to test an integration of units if each unit has been tested against collaborator (mocks) and interface contracts?

Question

Given: Let's say I have 3 objects A, B, C that form a cluster. Each unit (A,B,C) is independently tested with mocked collaborators. The "integration" is the call to A that calls out to B and C based on some conditions (e.g. either both are called or only B is called, say).

Testing Approach:

• Unit test for A relies on mocking interfaces of B, C and testing that A interacts with the interface correctly.
• Unit tests for B, C, relies on the correct data being passed into their method(s) and the tests actually are testing B, C against their interface "contract". Assumptions made by A are being tested for in tests for B, C

For the sake of simplicity, let's assume, neither unit makes any calls to databases or other systems...everything is "in memory".

Problem: A senior engineer on the team says: You haven't really tested that the overall functionality exposed by A is indeed working! Everything is testing against mocks!

Argument: One can write a simple "unit integration" (pardon the term) for a simple scenario as a sanity check if needed but it isn't really necessary if we're testing like the above, no?

Question: What is the flaw in the argument above and how to best answer the engineer's question?

From my POV, the tests are "technically complete" making it rather unlikely that once concrete implementations of B, C are wired into A, there's a chance something will break. What's the best way to frame the counter argument that makes such a "unit integration" test unnecessary (or what's the flaw in my understanding that I need to update)?

The above is a simplified view of the way we have testing structured in the repo where the "outside world" is only interacting at the "edges" and the core of the business logic is entirely unit-testable.

Answer 1

The justification I can see for writing an integration test using concrete instances of A, B, and C is to guard against assumptions made in tests drifting out of sync with the concrete B and C classes. To be honest, I was expecting that B or C were making calls out to a database, web service, or the file system.

If interfaces for all three classes exist because you are leveraging polymorphism, then there is nothing wrong with wanting example tests using the concrete objects to verify the cluster is functioning together. Tests for each class individually will make assertions based on assumptions about how those collaborating objects interact. If you cannot verify a change in one of these collaborators using a compiler, then there is a chance the logic of B and C could drift away from the expectations defined by tests for class A. This is simply the price you must pay for utilizing polymorphism.

If interfaces were created so you can mock things in testing, and there is no communication to the outside world, why even have interfaces? Use the real things throughout. That would be the design flaw causing your colleague to ask for additional tests.

So, my advice is twofold:

• If you are actually using polymorphism, your coworker is right. You'll need to add integration tests for all concrete actors. This is a reasonable request, in my opinion. You don't need many tests, though. Just enough to feel confident that the cluster of classes is cohesive.

• If these interfaces only exist so you can mock things in unit tests, get rid of the interfaces. Everything executes in memory inside a single thread. The interfaces are unnecessary. Your tests will verify the real behavior, which makes your coworker's request redundant.