The trickiness comes when you have to write these mocks, and whether the mocks are based off of correct assumptions. Granted, Haskell's type system goes a long

The trickiness comes when you have to write these mocks, and whether the mocks are based off of correct assumptions. Granted, Haskell's type system goes a long way to helping with that (often a function of type A -> B only has a handful of possible definitions given sufficiently complex types A and B), but it's still worth using actual production-use code paths when feasible. EDIT: Where I work, we have a large amount of tests, but we have pretty much never deployed an instance of our application without having every test pass. The idea of having 100% of your tests pass is a lot easier when it's the default, and when you're doing more continuous integration. If you're using a language like Haskell, your business logic will already be pretty separate from the ickiness of the IO layer, so most of your tests will be deterministic and nice by default. If you're using a messier language... well there's a lot of test suites out there. If you're using something that's mainly Django/Rails-y stuff, you don't have many excuses not to be 100% passing by default. Most major frameworks/languages offer extensive mocking tools and the like to avoid non-determinent behavior in tests.