> DHH largely creates a straw man: the fanatical, religious TDD devotee who blindly worships at the Altar of Unit Tests.
That's not a straw man: That's real life. I've worked with people like this. They're fairly common in TDD shops. You even see them on Hacker News making spurious claims like how TDD would have prevented the <security hole> in <framework> (nevermind the fact that that <framework>'s dev teams is heavily invested in TDD)
I've seen code bases designed from the tests first and they were pleasant to work with.
I've worked jobs where it was my responsibility to salvage undocumented, untested legacy code and extend it with new features while keeping it running.
The truth is rarely in the extremes being characterized in these blog posts and discussion threads.
The only kind of test code I've seen that required far too many mocks and dependency injections tend to result from poor design choices and writing the tests after the functionality.
If TDD as a practice doesn't work for you, that's fine -- but I think it's disingenuous to offer no alternatives. Integration testing isn't an alternative; I use them in concert with a well tested code base. And I use whole-system tests too.
DHH works in a small corner of the field. TDD may not work well for Rails applications is all I've been able to glean from his posts. I think that's a battle for the Ruby/Rails community to have. It doesn't discredit TDD one bit.
> TDD may not work well for Rails applications is all I've been able to glean from his posts.
And even this is not the case - the Ruby/Rails community is heavily involved with TDD/testing frameworks/etc, because it is so easy to do and because unit tests can help bring some of the assurances you miss from static typing back into your systems.
The issue DHH has with TDD is, imo, all wrapped up in the issues he has with design patterns, service layers, etc. Doing TDD on a business domain object that subclasses ActiveRecord::Base forces you to mock/stub all sorts of DB calls (which is irritating), which in turn highlights the fact that, contrary to what DHH says, it's not always a very good idea to stick all of your business logic in the model layer.
Normally in the model; but often in Rails the "model" gets conflated with the "persistence layer." Many of us who develop in Rails feel that the persistence layer should have the single responsibility of persistence, and would like to use something like a DAO pattern there, keeping business objects / logic in pure Ruby classes.
Note that this is not necessary for small, simple Rails applications: by all means, if you're writing a blog app, stick everything in AR::Base and don't over-design. But once you start working in large-scale, non-trivial Rails apps, it becomes very painful to have to have all of your tests running against your database for example.
This is probably something of an idiosyncrasy of Rails, and may have little relevance to other frameworks / languages.
I've worked for one of the biggest agile consultancies around, and while most of the developers write unit tests, I never met anyone who started frothing at the mouth if we wrote code before tests. I just don't buy the pervasiveness of these TDD-devotees to the degree that justifies all of this backlash, DHH articles, HN comments, etc.
And I've worked in TDD shops for years and never seen the fanatical TDD devotee. I have seen lots of developers that will use any excuse they can find not to provide automated tests for their code.
That's not a straw man: That's real life. I've worked with people like this. They're fairly common in TDD shops. You even see them on Hacker News making spurious claims like how TDD would have prevented the <security hole> in <framework> (nevermind the fact that that <framework>'s dev teams is heavily invested in TDD)