DHH’s point wasn’t that the tests were bad, but that TDD leads to ‘test-induced damage’. Having seen many code-bases written with unthinking TDD, I’d tend to agree.
The wonderful quality of such an assertion, however, is that it’s what Karl Popper would call a falsifiable statement. I also believe that it’s possible to falsify it, in the sense that it’s possible to use TDD to arrive at code that has no test-induced damage. As it turns out, this is much easier to do with functional programming than with object-oriented programming.
Most of this episode discussed unit testing in an object-oriented context, I think. Some practices and techniques stay the same in functional programming, but others differ. One of the most amazing changes happens when you start using property-based testing instead of example-based testing.
This is still unit testing, in my opinion, because it doesn’t touch boundaries (I don’t agree with Jay’s lack of definition of the term), but it’s another way of looking at testing. Some of the opinions put forth in this episode, such as only expecting literals, conflict with this sort of technique, though.
It’s hardly ‘early days’, though, as QuickCheck has been around since 1999.