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.
To address your second claim - doing IO in tests does not mean testing IO.
I just got the sense that the author was saying that the your tests have to cover every possible failure mode of IO and that’s just silly. IO should have its own tests. This goes back to your “expectation of a contract”.
Not sure if the author doesn’t understand the purpose of mocking or if they’re just being disingenuous.
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.
I just got the sense that the author was saying that the your tests have to cover every possible failure mode of IO and that’s just silly. IO should have its own tests. This goes back to your “expectation of a contract”.
Ah, I didn’t get that impression myself, but looking at the article again I can see it.