“It doesn’t work.”
“That’s because you’re not doing it right.”
Am I talking about TDD or am I talking about conservative economics?
I get the same argument about agile/scrum (let’s stop pretending they’re different things). Tons of worthless meetings, productivity drops sharply, so let’s have a three-hour meeting to talk about how to improve our productivity. Maybe you all need to increase your work week from 60 to 80 hours so we can meet our trade show dates.
I am not going to read Glen Beck. He was involved in the idea of pair programming so I would rather see him buried alive than give him any money. Pair programming put me into therapy even though I quit my job at Microsoft rather than do it a second time.
And TDD absolutely is whitebox testing; blackbox means, explicitly, that the person writing the tests has no knowledge of the code. Since it’s fundamental to TDD that developers test their own code, usually alone (this is it’s biggest flaw) then it is whitebox by definition.
Look, Mr. Keränen, I am not stupid. I’ve been a developer since 1988 and I have tons of achievements and am judged as a reliable developer who produces high-quality work. And I do design documents, not pre-code tests based on guesswork. In fact I will not take a client who expects me to work without a spec. Which I usually write, since I double as a technical writer.
You have not addressed any of my arguments, just recited how it should work. I will answer yours.
You say that 95% are doing it wrong, that if only everyone faithfully followed the book it would work. I wonder … if someone actually did that, made the entire development group attend classes and set up a structured environment to assure that the guidelines were being followed, and the results didn’t support your belief, would you change your tune? Would you abandon TDD because it doesn’t perform as well as its Uncle Bobs believe?
My introduction to this unit test shit, repeat, shit, was from a manager who wanted me to tear apart my release-ready application, which was only a half-dozen pages of code, to write unit tests for it. Before the conversation was over he was telling me to write new code, not even connected to the app, and write unit tests for that. So they could check that box: “this project has unit tests.” A most inauspicious introduction. Hardly inspiring confidence.
When he introduced me to the idea of TDD (it was new then) I made sure I had a clear path to the exit because he was clearly a lunatic. For reasons I wrote in my articles.
Tangentially, I am deeply unnerved by the fanaticism I see around all these new “methodologies,” but TDD most of all. They remind me of the gun nuts in my country. We don’t need design documents; the unit tests are more important than the code; anything short of 100% code coverage is dereliction of … duty.
This is psychiatric material.
And the worst of all is the idea that developers should be solely responsible for testing their work. Maybe that isn’t according to Hoyle but that’s what pretty much everyone I have discussed this with believes, and if I have to explain the problem with that then the chasm is too broad to bridge.
Not that any of this applies to me. I have not worked onsite since 2010, I mostly freelance, and my clients don’t care if I follow some fads or not. As long as I deliver, and I do. But I am 66 and my working days are drawing to a close. I’ll learn new languages like Rust and Swift but I am not wasting any time on fads like scrum or TDD. I’d rather do real work than metawork.
The flaws in TDD are not subtle nor are they abstract; they are fundamental. If you read responses and arguments you will see that enthusiasm for the methodologies is limited to those who have never worked any other way.