I’m looking for information about the successes and failures related to defining mocks, whether for testing (the typical case) or for dev activity.
The documentation for unit test tools seem to place a big focus on “create mocks and you won’t have to have access to the remote server you’re developing/testing the integration for!” (ignoring for the moment the view that one system calling another is by definition not a unit test). To me the emphasis on this is usually overdone.
IME, creating really useful mocks, ones that will help uncover errors in your integration components, and last longer than just the current project is really, really challenging. Imagine mocking the SFDC API in any reasonable manner. Sure, you might be able to do so for a few objects and few cases, but how long will that be useful? How much time and effort will you need to spend to do so? Will you spend more time maintaining the mock than the integration code? Is the bug that was reported in the integration code or caused by the mock being wrong or out of date? Why not just connect to the real thing and deal with aspects of that?
I’ve done some limited mocking in the past but abandoned it pretty quickly due to the above items. It has always been easier and more robust just to connect to the real thing. There are limitations certainly (e.g. repeatability of data creation) but one gets real results, not fake tends-to-be-from-the-happy-path-point-of-view responses.
But I’m looking for alternate experiences and points of view.