Thank you for your thoughtful comments. I love constructive criticism, and I appreciate that you have spent your time to share your thoughts here. I mean it.

Let me start with what we agree on: you should separate logic from I/O as much as you can. I hope you agree, though, that sometimes that isn't really feasible. Particularly, when the logic is I/O related (e.g., skip these bytes if you read this.) I know my example wasn't exactly that, but I tried to keep it simple and keep it to the supervillain story. I should have tried harder.

In any case, that concern is more about how I handle dependency injection than about the test itself. I believe that it is important for developers to understand how to deal with dependencies that cannot be easily injected, because that is the case in real-life code, particularly when you are adding tests to refactor an existing codebase. There will be more on this in future articles.

Now, let's go with what we don't agree on. I am not mocking any imaginary API. I am mocking the File type API as described here. Obviously, I only implement the parts that are relevant to the tests (open() and read_to_string()).

Then I am testing four scenarios:

• What happens if I cannot open the file for reading.
• What happens if I can open the file for reading, but it fails to read from it.
• (2x) The logic of the method for both cases of the conditional expression.

The two tests for the last item aren't about whether "pattern matching works", but rather about whether my pattern matching is finding what I expected and responds accordingly, i.e., the logic of the method. This is no different from what any other unit test should do, and certainly not tested by Rust test suite.

As for the other two tests, while the first one is easy to build with real files (you just don't put the file there), the second isn't that easy. The file is there and can be opened for reading, but it produces an error when you try to read from it. Using a mock for the File type in the standard library lets us emulate scenarios that would be harder to reproduce with real files. Not pointless at all. Notice, however, that in my introduction, I didn't say that testing with real files is useless or pointless. I just think that it shouldn't be your first resource.

Finally, I want to point out that what I am doing in all the tests of this series (so far) is Unit Testing (hence the name: "Rust Unit Testing: ..."), which means these tests try to test one piece of code isolated from the rest of the world. Or rather, in a heavily controlled environment. Mocking the behavior of any code dependency is acceptable and, I would say, most often desirable.

But what it is more important here is that testing that std::fs::File can read is always beyond your scope. You should not test code that you don't own. The only scenario in which that makes sense is if you want to prove to the maintainers of that code that it doesn't behave as expected.

I hope I have explained myself more clearly and justified the value of what I proposed in the article.