It's nice to see an article about developer-centric test automation that's isn't obvious trolling.
The distinction he makes between statist and mockist tests is an important one (although I tend to use the terms "state-based" and "interaction-based" when I make that distinction myself). Knowing what your strategy is for confirming that the code under test actually works is too often overlooked by testing newbies.
Please tell me if I'm wrong, but quickly skimming this it seems this only applies to dynamic laguages with no static typechecks what so ever at compile time (if there's even such a thing).
While I see the good stuff about dynamic, less strict languages, especially during the modelling & exploration phase, I still say that the fact that these kind of problems cannot exist in a statically typed environment is still one of the reasons I don't feel like converting to more dynamic languages for any production-class code I write.
When even your tests can pass without revealing broken class-interface contracts, you are way beyond what I find reasonable to check for myself. Your dynamic freedom forces you to do checks which even with a decades old compiler you could have taken for granted.
The distinction he makes between statist and mockist tests is an important one (although I tend to use the terms "state-based" and "interaction-based" when I make that distinction myself). Knowing what your strategy is for confirming that the code under test actually works is too often overlooked by testing newbies.