Hi Camin.

The problem is that mocks are inaccurate and often out of date. Component contracts specify fields and data types, but they cannot specify semantics. Your code might misunderstand the meaning of a field in someone else's API. And then there are temporal semantics - things happening in unexpected sequence, which is common for real time systems, which microservice based systems are.

And if someone misuses _your_ API (contract), you might think "that's their fault - not my problem" - but tell that to the product owner who oversees the entire product. So it is in the best interest of everyone if integration tests are run frequently, so that you don't find out that someone is misusing your stuff until weeks later - because their mocks reflect their incorrect understanding of your stuff.

That's why I generally feel that a mock of a component should be maintained by the owner of the component - not by the users of the component. But even so, mocks can be wrong, or incomplete, or miss edge cases, or not represent temporal behavior.

Yes, contracts are essential; component testing is essential; but these do not substitute for integration testing. It would be like a car manufacturer saying, "We tested the break assembly, and we tested the engine assembly, and all the others - so why do we need to test the whole car?"

Would you get behind the wheel of such a car?