Fast tests are awesome, but hard to achieve - at least for me. TDD advocates: prove DHH wrong with easy to adopt frameworks and working software, not blog posts or books.
Gary Bernhardt's about as credible on this as one can be, as he's literally recorded hours of himself building working software with TDD.
From the article:
These tests are fast enough that I can hit enter (my test-running keystroke) and have a response before I have time to think. It means that the flow of my thoughts never breaks. If you've watched Destroy All Software screencasts, you know that I'll sometimes run tests ten times per minute. All of my screencasts are recorded live after doing many takes to smooth the presentation out, so you're seeing my actual speed, not the result of editing.
I understand disagreeing, but responding to this post with "show, not tell" just makes it look like you haven't read the article.
It was a terrible idea. It only worked well if you applied the same discipline that you would've had to apply when doing it manually, but it lured you into a false sense of security when using it sloppily.
(Dingus is fine when used as a standard mock/stub/spy library, but the automatic isolation features are dangerous and are documented as such in the README.)
But still, after watching the videos, I can't do what Gary does. I'm not that good, and nobody I have ever worked with is that good either.
For the common developer to achieve Gary-like performance, the tools/frameworks/conventions have got to improve. IMHO.
In time I expect this will happen, and that DHH will be proven wrong! :-)