[vkou]

That depends on what your error recovery plan is.

If the code's running in a space shuttle, you probably want to test that path.

If it's bootstrapping a replicated service, it's likely desirable to crash early if a config file couldn't be opened.

If it's plausible that the file in question is missing, you can absolutely test that code path, without mocking open.

If you want to explicitly handle different reasons for why opening a file failed differently, by all means, stress all of that in your tests. But if all you have is a happy path and an unhappy path, where your code doesn't care why opening a file failed, all you need to test is the case where the file is present, and one where it is not.

[1718627440]

Modifying the file system to be would be kind of like mocking to me. I very much, don't want my daemons or user-facing applications to just crash, when a file is missing. That's kind-of the worst thing you can do.

[vkou]

> Modifying the file system to be would be kind of like mocking to me.

Modifying the file system's implementation would be. Including a valid_testdata.txt and an invalid_testdata.txt file in your test's directory, however, is not 'modifying the file system', any more than declaring a test input variable is 'mocking memory access'.

> don't want my daemons or user-facing applications to just crash, when a file is missing

If the file is important, it's the best kind of thing you can do when implementing a non-user-facing service. The last thing you want to do is to silently and incorrectly serve traffic because you are missing configuration.

You want to crash quickly and let whatever monitoring system you have in place escalate the problem in an application-agnostic manner.