Arguably this is a problem in when the patch is unapplied.

Presumably in the coverage case it’s being called by a trace function, which inevitably runs during test execution — and while we want the trace function to be called during the test function, we really want it without any patches the test function is using. But this arguably requires both an ability for the trace function to opt-out of patches and for the patcher to provide a way to temporarily disable all of them.

It is worth pointing out that you can often use containerized services as an alternative to mocking.

> In Why your mock doesn’t work I explained this rule of mocking:

> Mock where the object is used, not where it’s defined.

For anyone looking for generic advice, this is a quirk of python due to how imports work in that language (details in the linked post) and shouldn't be considered universal.

Why even mock anything in this example? You need to read the source code to work out what to mock, reaching deep inside the code to name some method to mock.

But what if you just passed in the contents of the file or something?

Edit: oh wait actually this is what the very last line in the blog post says! But I think it should be emphasized more!

I feel like the #1 reason mocks break looks nothing like this and instead looks like: you change the internal behaviors of a function/method and now the mocks interact differently with the underlying code, forcing you to change the mocks. Which highlights how awful mocking as a concept is; it is of truly limited usefulness for anything but the most brittle of tests.

Don't test the wrong things; if you care about some precondition, that should be an input. If you need to measure a side effect, that should be an output. Don't tweak global state to do your testing.

This blog post talks as if mocking the `open` function is a good thing that people should be told how to do. If you are mocking anything in the standard library your code is probably structured poorly.

In the example the author walks through, a cleaner way would be to have the second function take the Options as a parameter and decouple those two functions. You can then test both in isolation.