I’ve answered this objection in at least one of my many articles. In my Part I I said that people write all tests for all “units” before writing any code. Agreed, this isn’t what Beck counseled; this is, however, what nearly everyone does.
Which matters more?
Fact is that people aren’t following the logic, they’re just having a jolly time and convincing themselves and each other they’re doing meaningful work.
But this does little to my objections:
- writing tests before development means constantly revisiting them as new discoveries are made in development, as they always are. This is minor; it’s inefficient but so are scrum meetings, so is illegible code, so is poor structure, so is interruption. What’s one more inefficiency in an industry that has gone adrift in a sea of bullshit?
- having developers bear primary responsibility for testing their own work, this is MAJOR. This is deeply, savagely, fundamentally wrong. When we had a dev lead advocate this I broke a rule I had kept for 25 years and recommended that he be fired, since it was likely he had never finished anything in his life. Eventually he was fired, not on my advice but because other than agitating for a one high-risk zero-gain change after another and condescending to the rest of us, he did literally zero work. I don’t mean “not much,” I mean absolutely none.
- TDD is in practice nearly useless. I’m not saying completely useless because once in a while it will turn up a bug, but it’s primarily for very junior developers, catching as it does a kind of bug that senior people just don’t make. I’m steeped in object-oriented programming, in separating interfaces from implementations, and I just don’t break things by changing other things. It just doesn’t happen. Ever.
Most TDD users write tests for the most obvious cases only. I don’t have a lot of experience in unit testing, the managers who have pushed me to do it have always been people I had already lost all respect for but I have done it and find it to be way, way more work than it’s worth. I do tracelogging, and when things fail I can find them in the logs immediately with a simple text search. The testers I work with absolutely love it. It doubles as most commenting so I only need serious comments when explainging the reasoning for some block or some but of logic.
There is also a lot of bullshit that comes along with TDD, it may not come from Beck but it’s there. That the unit tests are the API documentation, this is fucking drivel. Anyone who believes that is an idiot. Same for 100% coverage. This may not be Beck either, but does it matter? It’s what way too many people believe.
Maybe they’d do better if they read the book, but they aren’t going to. They probably can’t concentrate well enough to read a book, they’ve grown up on games and channel-surfing and their workplaces are endless interruptions.
As for Beck, it’s come to my attention that he is one of the people behind Extreme Programming, one component of which, pair programming, has done me grevious psychological harm. Eleven years after a single session of it I am in counseling, trying to get it behind me. Anyone who could be so demented as to believe that working ion constant communication as a way to achieve software development is someone I want nothing to do with. That is psychotic. Software development is a solitary activity with cognitive focus at its foundation. The industry has so lost sight of this that I will almost certainly never work onsite ever again.
I’m freelancing and remoting, no scrums no meetings no no no never again.