4 ms·
Mocking file system or network seems counter productive. Complicated logic can be in pure functions and not be intertwined with IO if it needs to be tested. M
by ozgrakkurt 1y ago
Mocking file system or network seems counter productive.
Complicated logic can be in pure functions and not be intertwined with IO if it needs to be tested.
Mocking IO seems like it won’t really capture the problems you might encounter in reality anyway.
- kolektiv 1y agoIt's not always about mocking (in my cases it hasn't been). Sometimes it is about multiple "real" implementations - a filesystem is itself an abstraction, and a very common one, it seems like it would at least sometimes be useful to be able to leverage that more flexibly.
- eru 1y agoI have a little system that takes a .git and mounts it as a fuse filesystem. Every commit becomes a directory with a snapshot of the project at that point in time. You could read the whole .git in at once, and then you'd have an in-memory file-system, if you wanted to. In any case, I agree with you: it's not about mocking.
- kryptiskt 1y agoSome examples where it would be useful: Exposing a zip file or exe-embedded data as a filesystem, or making an FS backed by 9P, WebDAV or SFTP.
- stingraycharles 1y agoSame like mocking databases; yes they make your tests run faster and more “pure”, but you’re suddenly not really testing reality anymore.
- boomlinde 1y agoSure, but they're not mutually exclusive approaches. Having tests that run in a couple of seconds thanks to low I/O and cheap scaffolding setup/teardown can be a valuable addition to slower, comprehensive system and integration test suites.
- actionfromafar 1y agoAnd you can spot differences between your understanding of reality (test mockups) and how it behaves on the real filesystem. (In this case.)
- Arch-TK 1y agoFault injection is much easier if you can mock IO. And you aren't really testing your software if you're not injecting faults.
- ozgrakkurt 1y agoMy point is, you can give gibberish data to a processing function if it just takes in-memory data instead of being parameterized by “IO”. If you parameterize everything by IO then you have to mock the IO
- Arch-TK 1y agoIt's not just about gibberish data. It's read failures, write failures, open failures, for a variety of reasons including permission errors, disk errors, space errors, etc. You basically want to test your code does something sensical with either every possible combination of errors, or with some random subset of combinations of errors. This can be automated and can verify the behaviour of your program in the edge cases. It's actually not usually that helpful to only test "we read corrupt garbage from the file" which is the thing you're describing here.