The author clearly doesn’t realize that they still mock in their examples. I understand the annoyance with mocking away the complexity, however.

To address your second claim - doing IO in tests does not mean testing IO.

I test my file interactions by creating a set of temporary directories and files, invoking my code, and checking for outcomes. That way I can write my expectation before my implementation. This doesn’t test IO, merely utilizes it. The structure in temp that I create is still a mock of an expected work target.

Very similarly I recently used a web server running in another thread to define expectations of API client’s behavior when dealing with a very ban-happy API. That web server is a mock that allowed me to clearly define expectations of rate limiting, ssl enforcement (it is a responsibility of an API client to initialize network client correctly), concurrency control during OAuth refreshes etc., without mocking away complexities of a network. Even better, due to mocking like that I was able to tinker with my network library choice without changing a single test.

Mocks in the general sense that author defined them are inevitable if we write software in good faith - they express our understanding and expectation of a contract. Good mocks make as few claims as possible, however. A networking mock should sit in the network, for example, lest it makes implied claims about the network transport itself.