I'm afraid I disagree. To me, integration tests are most important any time your type checker can't do the work for you.
Databases are one key example. Can you put your data in, and then get it back out again? You can maintain unit tests to be sure that the "in" part works and the "out" part works, but if those two tests get out of sync you'll never know. And now you're maintaining two separate mocks, rather than just using the real thing on both ends.
Similarly, you have to integration test when your data passes over the wire. Why mock the client to test the server, and mock the server to test the client, when you can just spin up both and test them together?
I prefer to write unit tests opportunistically. If I need to throw together a separate environment, especially in a test-driven-development sort of way, I write a unit test. And having written it, it remains.
But if I'm aiming for 100% code coverage I'd rather let my integration tests do that. Because integration tests test pathways that unit tests just can't, and so "100%" doesn't mean anything if the testing environment is wrong.
Databases are one key example. Can you put your data in, and then get it back out again? You can maintain unit tests to be sure that the "in" part works and the "out" part works, but if those two tests get out of sync you'll never know. And now you're maintaining two separate mocks, rather than just using the real thing on both ends.
Similarly, you have to integration test when your data passes over the wire. Why mock the client to test the server, and mock the server to test the client, when you can just spin up both and test them together?
I prefer to write unit tests opportunistically. If I need to throw together a separate environment, especially in a test-driven-development sort of way, I write a unit test. And having written it, it remains.
But if I'm aiming for 100% code coverage I'd rather let my integration tests do that. Because integration tests test pathways that unit tests just can't, and so "100%" doesn't mean anything if the testing environment is wrong.