3 ms·
Give it up. Mocks are mostly useless. If you want testable code, the first step is to separate computations from effects. Most of your program should be immuta
by loup-vaillant 8y ago
Give it up. Mocks are mostly useless.
If you want testable code, the first step is to separate computations from effects. Most of your program should be immutable. Ideally you'd have a mostly functional core, used by an imperative shell.
Now to test a function, you just give it inputs, and check the outputs. Simple as that.
Oh you're worried that your function might use some other function, and you still want to test it in isolation? I said give it up. Instead, test that other function first, and when you're confident it's bug free (at least for the relevant use cases), then test your first function.
And in the rare cases where you still need to inject dependencies, remember that most languages support some form of currying.
- vkjv 8y agoThis. I'll also add that in the world of things like Docker and [Insert]CI you don't need to mock most external dependencies like databases.
- humanrebar 8y agoThat's a solid plan for acceptance testing and a great way to make sure you can never test diagnostic, recovery, rollback, and other something-abnormal-happened-here logic. For small programs with few interfaces to worry about, that might be fine, but as you number of users go up, the odds go up that you'll be ensuring rollback bits get flipped when filesystems fail. None of that is simple to test without some sort of dependency injection or other heavyweight design pattern.
- yen223 8y agoWhy would you use mocks to test those things?
- humanrebar 8y agoBecause manually triggering an optimistic locking failure is a pain. Triggering one of those and a filesystem write failure at the same time is a whole pile of work compared to the mocking.