The Mock objects in TDD are there so that after a test you can check that the code under test caused side-effects in dependant objects. (At least, most of the t

The Mock objects in TDD are there so that after a test you can check that the code under test caused side-effects in dependant objects. (At least, most of the time this is why they exist.) Functional programming is very much about decoupling "pure functional" computation and side-effects. Using pattern matching you can quite easily write a little machine that performs side-effects given different values. These things are simple and about as useful to unit-test as accessor methods are in oo code. Static typing checks do fine. Also, if it is broken, it tends to be severly broken and not lead to undetected or hard-to-find bugs but simply not work at all. The interesting code to test is that which is given a bunch of parameters and returns a value that would instruct the side-effectful machine about what to do. This function can be tested with lots of inputs, and you check that it gives the correct instructions (without executing them). This style of programming exists in OO as well. Another reason to use Mocks is that they are queried for values that one need control over to rig the unit test. I.e. just a disguised parameters. FP simply doesnt do that.