[neurotrace]

I'd argue that you should have thorough unit tests for each service to ensure that they always respect their public API. Additionally, in a monorepo you can share type definitions so regardless of the service, you know for sure that you're using the right API. If all of that is in place then you can test the integration by just mocking out those services rather than testing their API n times.

If you're in an environment where you have limited/absence of type checking then you're right. In my experience, most problems that come from the integration of networked services come from not properly accounting for all possible responses. You're expecting to get a 200 response and a field of `x` but you got a 204 so the response is empty. That sort of thing.

[Spivak]

This is easy when you own all the code, it's a god damn nightmare the moment you introduce code that isn't yours like Redis, Postgres, Elasticsearch, every cloud API.

If you're assuming that the hundreds of millions of lines of other people's code totally outside your control always follows its spec, doesn't have bugs, or can change out from under you with no version bump (yay cloud) you're gonna be bit hard and then have to invest in integration tests.

[neurotrace]

Good point. I have always run integration tests with Postgres etc. and have found value in it. I do think that you should have a substantially smaller set of those sorts of tests though.