4 ms·
I write Haskell in production. One of the things we've built is a unit testing harness that denies application-level code any access to unrestricted IO. If a
by implicit 11y ago
I write Haskell in production. One of the things we've built is a unit testing harness that denies application-level code any access to unrestricted IO. If a proper mock is not in place, type checking fails before the tests even begin to run.
All tests are thus 100% reliable and parallelizable.
This capability of isolating and controlling side effects makes Haskell very uniquely well-suited to applications that need to withstand a lot of maintenance by a lot of people for a very long time.
- pka 11y agoCould you elaborate more or point to some sample code?
- implicit 11y agoSure. I've previously written up a short description of the approach here: http://andyfriesen.com/2015/06/17/testable-io-in-haskell.html http://andyfriesen.com/2015/06/17/testable-io-in-haskell.htm... The general high-level approach is that your business logic functions run in some monad, constrained by the set of capabilities it requires. Each capability is represented as a typeclass. Your type signatures say that your business actions work in every monad that supports those capabilities, so the type checker rejects any code that tries to use "unblessed" side effects.
- pka 11y agoThanks, that's a cool approach! I'm wondering if a free monad approach would have any advantages over this.
- tel 11y agoIt's similar and there's some endless debate over comparisons of various effect handlin systems. I like the one the op recommends because it's fast and lightweight, but free works just the same. Free is really necessary if you're going to be doing lots of introspection of the monad values where you'd still probably want to write your functions against such a typeclass stack but then translate the values out as free transformer stacks.