 <p>"I'm thinking more TDD, like in an OOP language. Is such a thing possible in Haskell?"</p> <p>A better question is "is such a thing <em>necessary</em> in Haskell?" ;-)</p> <p>[I realise that is not the question you actually asked. Feel free to ignore this answer.]</p> <p>In an OO language, we build objects that talk to other objects to get their job done. To test such an object, we build a bunch of fake objects, hook the real object up to the fake ones, run the method(s) we want to test, and assert that it calls faked methods with the expected inputs, etc.</p> <p>In Haskell, we write <em>functions</em>. The only thing a pure function does is take some input, and produce some output. So the way to test that is to just <em>run</em> the thing, feeding it known inputs and checking that it returns known outputs. What other functions it calls in the process of doing that doesn't <em>matter</em>; all we care about is whether the answer is right.</p> <p>In particular, the reason we don't usually do this in OOP is that calling some arbitrary method might cause "real work" to happen &mdash; reading or writing disk files, opening network connections, talking to databases and other servers, etc. If you're just testing one part of your code, you don't want the test to depend on whether some database is running on a real network server somewhere; you just want to test one little part of your code.</p> <p>With Haskell, we separate anything that can affect the Real World from stuff that just does data transformations. Testing stuff that just transforms data in memory is delightfully trivial! (Testing the parts of your code that do interact with the Real World is still hard, in general. But hopefully those parts are very small now.)</p> <p>The Haskell test style of choice seems to be property-based testing. For example, if you've got a function to solve an equation, you write a QuickCheck property that randomly generates 100 equations, and for each one, it checks whether the number returned actually solves the original equation or not. It's a tiny handful of code that automatically tests just about everything you'd ever want to know! (But not quite: You need to make sure that the "randomly" chosen equations actually test all the code paths you care about.)</p>