3 ms·
Unit tests are fine for testing side effects if you've written the code properly with proper interfaces, etc. You need to test that you're using the contracts
by gnusty_gnurc 6y ago
Unit tests are fine for testing side effects if you've written the code properly with proper interfaces, etc.
You need to test that you're using the contracts you've made, and integration tests verify that everything works as expected when both sides are complying with the contract.
I'm saying that if I've abstracted out the filesystem into an interface the distinction of asserting against whether a method was called on that interface and asserting a side-effect is somewhat trivial. I've made it so that side-effects must be handled in integration tests.
- u801e 6y ago> I'm saying that if I've abstracted out the filesystem into an interface the distinction of asserting against whether a method was called on that interface and asserting a side-effect is somewhat trivial. But now you're enforcing a degree of coupling between your filesystem interface and your code. If you refactor the filesytem interface such that the overall logic hasn't changed, but the parameter order for one of the methods is updated, then you essentially double the amount of work you have to do (update the code and update the tests). If you just test the logic and not the interface, then you only have to update the tests that pertain to the logic itself. You should read up on the concept of functional core/imperative shell.
- gnusty_gnurc 6y agoAh ok, I see what you're saying. I've seen the talk "Hoist your I/O" by Brandon Rhodes. He mentions that but I don't think he went into detail about commands/events or any of that stuff.