[implicit]

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]

Could you elaborate more or point to some sample code?

[implicit]

Sure. I've previously written up a short description of the approach here: 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]

Thanks, that's a cool approach! I'm wondering if a free monad approach would have any advantages over this.

[tel]

It'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.