[jasonpeacock]

The system I described is actually a cloud system, and we had both stubs and mocks of all our dependences (which is easy, because they were other cloud systems and we could easily stand up a fake service with the same API when doing integration tests, or switch to use local data when doing unit tests).

We also performed testing against live dependencies but with test accounts to ensure that our stubs/mocks were accurate and up-to-date, and captured realistic interactions (and failures).

I've done the same with hardware systems, again using stubs/mocks of HW dependencies for unit tests and then using actual HW for integration testing.

The time spent investing in stubs/mock quickly pays dividends in both increased development speed and test coverage, especially as you can inject faults and failures (bad data, timeouts, auth failures, corruption, etc).

[k__]

I also read about tests that compare the mockups and stubs with the original implementations, but it sounded like overkill to write tests for your tests.

[jasonpeacock]

Yes, at some point you get diminishing ROI :) We were OK with having the pipeline fail due to a change in the live API that our mocks didn't emulate, then we'd go update our mocks (and fix the code).

It happened infrequently enough that it wasn't worth the effort to automate the testing of the mocks against the live APIs.

Though honestly, for internal APIs owned by sister teams, this was usually due to a bug/non-backward-compatible change on their side, and we'd work with them to fix their APIs.