Giving Up on TDD

TDD at this point is kind of wasteful because if you decide to backtrack or rework aspects of the design then you have to also rework all of the tests. I find that once the design begins to crystalize, adding unit tests at this point is valuable, but not necessarily in a 'test-driven' way.

TDD by itself, per se will not automatically produce a good design, and can often produce bad designs with huge proliferation of classes / interfaces that makes a codebase more complex and difficult to understand.

TDD is not the be all and end all that some commentators seem to believe.

The benefits of X are always lower than any naive adopter thinks? That's quite a claim. Would you care to justify that? Heck, don't even worry about the general case, just explain it for this one.

I've been doing TDD for many years at this point. Right now I'm working on a hobby project where I was intentionally sloppy about testing, just to see how little I could get away with. The answer is: in the long term, I can get away with surprisingly little. But there's a lot of subtlety in exactly how and when the benefits come, and when exactly sloppiness is ok.

Given that I'm still learning about the benefits of TDD despite many years of practice and thought, I'd say there's no reason to think a novice would have a particularly good idea. Maybe their expectations are unrealistically low, maybe high. But more likely it's both and neither. Maybe one's very notion of "benefit" changes over time. TDD has certainly done that for me.

Heck, when anesthesia was introduced, people thought it was a needless luxury and an interference with the pain God intended us to have. [2] And they were right in the way you were right: billions had just lived with the pain, so anesthesia wasn't really necessary. But something can be unnecessary and still be a good idea.

[1] https://www.google.com/search?site=&tbm=isch&q=software+proj...

[2] http://www.newyorker.com/magazine/2013/07/29/slow-ideas

I do it, and I find it valuable. But I think if you're not using it as a design tool, you're missing most of the benefit.

You don't do TDD (IMO) to prove correctness. You do it to achieve a level of composition and design that makes later requirements changes and refactoring less painful. Proving that your stuff actually works is a convenient side effect. But not the primary goal because tests have costs.

I haven't followed Osherove for years, so maybe his thinking has changed, but it used to be common to think of chasing high test coverage numbers as an anti-pattern. 70 to 80% is the sweet spot. You're designing. You're being productive. That last 10, 20 or 30% of coverage gets exponentially more expensive both to develop and maintain, and it provides no additional design benefit. It's only testing for it's own sake.

BDD and the culture that sprang up around it (at least in the Ruby community) was such a disappointment after having done TDD for a few years previous. It's like every known anti-pattern was adopted as a core deliverable and the entire point of the exercise (IMO, solving the "blank page" problem in building systems; Design) was forgotten entirely.

It's my experience that Developers who've adopted this style of "TDD" are cargo culting, and incredibly difficult to work with. Reason didn't get them into the belief. They can't be reasoned out of it. It's religion by that point.

Now that I'm in Scala, and TDD my own code, I'm a very happy developer. I never suffer blank-page issues. I never bother writing tests after the fact. I don't often encounter bugs in such code, and they're almost never fundamental design issues when I do. And my coverage proudly hovers around 70%.

That is how you TDD right IMO. Follow the lessons learned a decade or more ago and avoid the anti-patterns.

Chasing test coverage is not only a good way to light piles of somebody else's money on fire by wasting time for little benefit, but it's actively harmful to the quality of your code base over the long term. You're disincentivized to correct design mistakes, and you're encouraged to over design to enable a level of testing granularity that never paid any concrete benefits for itself in the first place.

I'm a solid proponent of TDD then. But it's like saying I think water is good and you can prove it when most people are trying to sell you "mineral rich" Iron tainted industrial runoff. TDD absolutely can increase costs and complexity in the wrong hands.

The moral of my rambling story is to be Agile I guess. In the original sense, not the consultation services one. To the inexperienced developer I'd say: Try to solve problems, not implement solutions. And above all, never cargo cult. When someone tells you you need 100% coverage, ask them what benefit it provides. When someone tells you to "measure everything", ask them if they've measured the business value of measuring everything and if it outweighed the opportunity cost and dollars sunk into the effort. Be a constant skeptic, because snake oil is everywhere.

Sorry for the diatribe. You took me down memory lane and I guess I feel pretty strongly about TDD.