I have to disagree with your last statement (integrated tests are a scam) very strongly. Think about it as follows: We assert unit tests are useful, because a

I have to disagree with your last statement (integrated tests are a scam) very strongly. Think about it as follows: We assert unit tests are useful, because although we may "trust" primitives (1+1=2) we can introduce semantic bugs in how we compose them. Does it not also follow that if our primitives are now "microservice functions" and our composition is the "integrated service", we should test the composition for validity? I truly believe in E2E testing, I could go on at length about esoteric bugs we found only in interactions between properly functioning microservices (Hell just today I watched a coworker work out a fun timezone doozie). One could make a feasible argument that with a more well defined set of constraints and capabilities, the microservice could have sufficiently covered unit test cases for all possible interactions from a stub perspective, but pragmatically, _this does not happen in the real world_, and E2E testing is a nice way of making sure your product is indeed continuing to not be on fire (mostly). One could feasibly (from my view of the world) say "Integration tests are a cheap fix", to which I'd say "yes, yes they are" and then continue to perform them, even if they are only in the form of a click through smoke test by hand after a prod deployment :)