Indeed. I think DHH was very specific in his criticism, that for controllers only, then TDD and unit tests aren't the wisest choice, because they introduce complexity and potential problems (really, are you sure all those mocks catch all your edge cases?).
The critics, including Kent Beck here, have by and large reducto absurdum'd it to "DHH HATES TESTING AND EATS BABIES", which isn't his point at all. Sure, DHH could have been more narrowly focused and less confrontational in his language, but that doesn't mean he's wrong.
Look at it this way... are controllers hard to test in Rails, or are controllers hard to test in general? This is an argument for lightweight controllers that are little more than routing glue (don't put business logic in controllers), and then giving them a pass on unit testing in order to keep them clean.
This gets to something I've been chewing on and should write about, which I think of as Tautology Testing. It's endemic in excessive unit testing. You create a mock so you can create a test so a test exists. The test doesn't really test anything except its own existence. How is that useful? You're just adding complexity, not functionality.
DHH's article looks to be titled 'Test-induced design damage', not 'TDD is dead'. 'TDD is dead' is referenced in the article as a current uprising (which I hadn't heard of, fwiw), not necessarily as something DHH personally believes. I thought his take on the issue was nuanced and thoughtful, so its surprising to see Kent's overreaction here.
The critics, including Kent Beck here, have by and large reducto absurdum'd it to "DHH HATES TESTING AND EATS BABIES", which isn't his point at all. Sure, DHH could have been more narrowly focused and less confrontational in his language, but that doesn't mean he's wrong.
Look at it this way... are controllers hard to test in Rails, or are controllers hard to test in general? This is an argument for lightweight controllers that are little more than routing glue (don't put business logic in controllers), and then giving them a pass on unit testing in order to keep them clean.
This gets to something I've been chewing on and should write about, which I think of as Tautology Testing. It's endemic in excessive unit testing. You create a mock so you can create a test so a test exists. The test doesn't really test anything except its own existence. How is that useful? You're just adding complexity, not functionality.