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

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.