Sure, go ahead, do all your tests for stuff involving I/O by doing real I/O, and do some containerization or whatever to maintain reproducibility. Don’t come crying to me when your test runtime goes from 10 seconds to 20 minutes, and everyone stops actually running them.
How to test without mocking
Submitted 5 months ago by bot@lemmy.smeargle.fans [bot] to hackernews@lemmy.smeargle.fans
https://www.amazingcto.com/mocking-is-an-antipattern-how-to-test-without-mocking/
Comments
fl42v@lemmy.ml 5 months ago
Sure, don’t mock. Just test in production
echo@lemmings.world 5 months ago
Not sure if the author doesn’t understand the purpose of mocking or if they’re just being disingenuous.
Slotos@feddit.nl 5 months ago
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.
echo@lemmings.world 5 months ago
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”.