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).
- 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.