> but unit tests in aggregate will cover a greater area.
If integration tests can't cover some part of your code, it's because that part does not matter. Get rid of it.
If integration tests can't cover some part of your code, it's because that part does not matter. Get rid of it.
I also disagree that whether an integration test can cover some part of your code is the litmus test for whether the code is relevant. There are types of errors that are relevant but complicated to simulate in an integration test, or at least in an automated integration test.
An example would be a network partition. It's involved to code a test to cause the partition, wait for the various timeouts to take place, then heal the partition, then wait some more for things to start talking and recovering. And depending on who owns the test environment and how your organization is managed, you may need to negotiate with a DevOps / Operations / Security person to get permission to run iptables in the appropriate machines.
On the other hand, unit-testing what happens when a connection fails is probably pretty easy.
Yet, on the layer that is charged with surviving a partition, that's exactly what you should be doing.
Your unit test can verify that some machine sends the designed message down the wire, it can check if it responds to the expected message, but it can not even check if the software can detect a partition, even less that it can survive one.
I would recommend you make those timeouts configurable from the user point of view.