Dispelling Myths About Test-Driven DevelopmentI've seen a lot of vitriol and misconceptions come from the TDD "debate". This post offers a balanced approach to a number of misconceptions propagated by both proponents and detractors.
It’s not often that I share someone else’s content like this, but Rob Myers just published an article that I kinda wish I had been smart enough and eloquent enough to write.
His introduction is incredibly familiar to me:
A while back I read a LinkedIn post where a Test-Driven Development (TDD) evangelist suggested something truly surprising and disagreeable to me. Not long after that, a client of mine sent a video of another TDD proponent, and asked my opinion. Surprisingly the proponent on the video seemed to have missed the point of TDD entirely.
I’ve seen a lot of vitriol from both “sides” of the TDD debate. And I’ve seen a lot of misconceptions from both sides.
Now if you’ve been following me for a while, you know I’m an advocate of TDD, but that’s not to say I think TDD is required. A lot of great software has been written by a lot of great people, who don’t use TDD.
But I do honestly think that knowing TDD can help virtually every developer. Not in every situation, but in enough situations to be worth being competent with the skill.
And this post helps to make that case, by taking a truly balanced approach to a number of misconceptions—misconceptions propagated by both proponents and detractors.
Without further ado, here’s the link to the article, which I hope you’ll read: Dispelling Myths About Test-Driven Development
What do you think? Agree? Disagree? Some other objection (or over-zealous claim) you’ve heard that you’d like to see addressed?
TDD and throw-away code
If I had started with test-first approach, I would have saved half a day or so.
TDD provides focus
TDD helps me avoid mental rabit trails of nice-to-haves and performance improvements.