An overly aggressive mock can work fine, but break much later

Honestly I don't buy it. Worse, this is one of the reason I prefer to do "minimal integration tests" instead of unit tests. Take the example snippet of code

    def get_user_settings() -> str:
        with open(Path("~/settings.json").expanduser()) as f:
            return json.load(f)

    def add_two_settings() -> int:
        settings = get_user_settings()
        return settings["opt1"] + settings["opt2"]

and the very first comment just below

>>> The thing we want to avoid is opening a real file

and then the article goes and goes around patching stdlib stuff etc.

But instead I would suggest the real way to test it is to actually create the damn file, fill it with the "normal" (fixed) content and then run the damn test.

This is because after years of battling against mocks of various sort I find that creating the "real" resource is actually less finicky than monkeypatching stuff around.

Apart from that; yeah, sure the code should be refactored and the paths / resources moved out of the "pure logical" steps, but 1) this is an example and 2) this is the reality of most of the actual code, just 10x more complex and 100x more costly to refactor.

That works fine for files, but what if the integration is with a third party service for example?

You can create an actual mock networked service but it's much more work.

I think this is an example explaining what seems like a good practice for using mocks in python to me, the actual code in the post is barely "supporting cast".