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

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.

> This blog post talks as if mocking the `open` function is a good thing that people should be told how to do.

It does. And this is exactly the problem, here!

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

No! No, no, no! You do not 'want to avoid opening a real file' in a test.

It's completely fine to open a real file in a test! If your code depends on reading input files, then your test should include real input files in it! There's no reason to mock any of this. All of this stuff is easy to set up in any unit test library worth it's salt.