He ignores the points DHH makes, and then replies with his own snide talking points like a politician on a sunday morning talk show.
Also, DHH argues against plenty of other best practices / design patterns and is considered incorrect in many of these cases (his "only use the Rails classes" objections to having a service layer most famously). It just so happens that when he bashes something that a lot of developers don't like to do already (write unit tests), the pitchforks rally behind him.
It's the same sort of thing when people post articles on HN bashing pair programming, or open workspaces. We get it. Some of you really don't like change, or anything "agile". Now please stop beating the dead horse already.
There's more than one way to skin a cat, and it isn't always fear of change that keeps people from changing.
Dear god, please take the straw man out back and shoot him already.
There really is no way to have an intellectually honest discussion about these subjects, is there?
When I see "agile" and "tenet" in the same sentence, I think "government shop". An explicitly flexible premise (Agile) does not have "one true way" to do anything.
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)
But yeah, they exist
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.
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.
DHH isn't having any of it, but by no means is he representative of the Ruby/Rails community here. (see: https://www.destroyallsoftware.com/screencasts/catalog/what-... for just one of many examples)
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.
Thanks for pointing that out though; I didn't intend to assert
dhh's opinion <=> rails community's opinionI'm not sure if you're exaggerating a little, but I think that having colleagues whose wrath makes you hesitant to express yourself is an entirely different issue from that of test-driven development or not. Development is a fairly easy field in which to demonstrate that you're at least as correct in your methodologies as another developer: just produce quality code. This feels (as these arguments very often feel to me) like a personality issue more than a methodological one.
I span that weird space between product and engineering though. So most of the time I'm hacking in something like "prototype" mode, so TDD just makes no sense. I approach it more like sculpting. I'm slowing hacking away at this block of marble to produce an elegant "beautiful" product. Once it start to take shape I can create tests and specs to define the learnings and creations that I've made.
Tests first? It just doesn't work for me.
If anything, if the adherents of TDD were to properly abandon it, then that would be TDD dying because they would have come up with something better or moved on.