The important part is that you are able to temporally decouple running the tests against the service mock, and the tests running against the real service. This

The important part is that you are able to temporally decouple running the tests against the service mock, and the tests running against the real service. This sounds very similar to Consumer Driven Contracts, such as https://docs.pact.io/ https://docs.pact.io/ You record your expectations towards the service mock, and then later verify that these expectations hold against the real service. This decoupling allows you to run your "end-to-end" test suite very often, say on every check in, and then only verify the contract say every hour or day, depending on how stable your test environments are. The theory is that this gives quicker feedback, reduce flakyness and avoid combinatorial explosion of number of tests needed to run.