2 ms·

I'm not sure I understand the hostility towards TDD I sometimes see here. It's true there are zealots -- people who think just because you've written tests you

by rquantz 13y ago

I'm not sure I understand the hostility towards TDD I sometimes see here. It's true there are zealots -- people who think just because you've written tests you will magically automatically have good design, and never have any bugs ever. But surely there are plenty of reasonable people who recognize there are trade offs, and find that writing tests first helps them make sure they're writing the interface they want to, ensures that test coverage is pretty good even if you don't have the budget/manpower for a whole QA team, and makes it easier to maintain the code, ultimately, since you'll be alerted to unintended consequences. People like the first commenter on the article are even more bewildering. You have to test your code. Why wouldn't you automate that?

CJefferson 13y ago
You see such hostility towards TDD for the same reason you see zealots. In general (I observe) the stronger some people argue for something, the stronger others will argue against. Also, this SMBC comic expresses how I think these things often end up working out: http://www.smbc-comics.com/index.php?db=comics&id=2939 http://www.smbc-comics.com/index.php?db=comics&id=2939
tbrownaw 13y ago
There is a big difference between "true" TDD and simply writing the tests before you write the code. According to the TDD evangelism I've seen, it means (1) writing tests one at a time, which should fail at the time that they're written; (2) after adding each test, write code that will past that one test while being deliberately ignorant of any requirements that will show up in future tests; (3) refactor, rewrite, etc, as needed as new tests are added. I suppose this could be meant to mimic how code in long-lived systems evolves as requirements are discovered and changed. Or it could be meant to promote awareness of you-aint-gonna-need it and reduce over-engineering. Either way it also will necessarily cause extreme short-sightedness and err strongly on the side of under-engineering, and in the case of mimicking natural code evolution it would be an example of cargo-cult thinking.
ddellacosta 13y ago
Agree. To me this smells like a lack of experience. TDD is what it is--for some parts of the process, I don't think it's appropriate--just like other "Extreme programming" practices. But TDD certainly has helped me write cleaner, simpler code in the past, and having a set of regression tests to fall back on has saved me time and time again (which, let's be clear, is separate from TDD). In fact, I spent this morning writing a good bit of TDD code, and in the afternoon felt like I had to finish something up and foolishly eschewed the testing ("I'll write 'em later!" right)...and I ended up spending more time mucking about with stupid errors, and ironically in the end wrote less code. This is anecdotal, but it has happened to me a good number of times. As a result, I tend to prefer TDD when I can use it. Sometimes I like spiking out a solution first, if I don't fully understand the algorithm, for example--but then I will often scrap it and re-write it with tests, which usually produces a more clear statement of the solution since I have already thought through it. From which follows my next point: of course writing tests, and TDD in particular, does not preclude thinking hard about your code's structure. But without experience testing, and especially doing TDD/BDD, I feel that it is very hard to understand the tradeoffs and challenges involved, as well as the pluses. So when I hear either a vehement denouncement or statement of support, I tend to suspect a lack of experience more than anything else. Although, I suppose Uncle Bob is a special case...

by rquantz 13y ago

CJefferson 13y ago

You see such hostility towards TDD for the same reason you see zealots. In general (I observe) the stronger some people argue for something, the stronger others will argue against. Also, this SMBC comic expresses how I think these things often end up working out: http://www.smbc-comics.com/index.php?db=comics&id=2939 http://www.smbc-comics.com/index.php?db=comics&id=2939

tbrownaw 13y ago

There is a big difference between "true" TDD and simply writing the tests before you write the code. According to the TDD evangelism I've seen, it means (1) writing tests one at a time, which should fail at the time that they're written; (2) after adding each test, write code that will past that one test while being deliberately ignorant of any requirements that will show up in future tests; (3) refactor, rewrite, etc, as needed as new tests are added. I suppose this could be meant to mimic how code in long-lived systems evolves as requirements are discovered and changed. Or it could be meant to promote awareness of you-aint-gonna-need it and reduce over-engineering. Either way it also will necessarily cause extreme short-sightedness and err strongly on the side of under-engineering, and in the case of mimicking natural code evolution it would be an example of cargo-cult thinking.

ddellacosta 13y ago

Agree. To me this smells like a lack of experience. TDD is what it is--for some parts of the process, I don't think it's appropriate--just like other "Extreme programming" practices. But TDD certainly has helped me write cleaner, simpler code in the past, and having a set of regression tests to fall back on has saved me time and time again (which, let's be clear, is separate from TDD). In fact, I spent this morning writing a good bit of TDD code, and in the afternoon felt like I had to finish something up and foolishly eschewed the testing ("I'll write 'em later!" right)...and I ended up spending more time mucking about with stupid errors, and ironically in the end wrote less code. This is anecdotal, but it has happened to me a good number of times. As a result, I tend to prefer TDD when I can use it. Sometimes I like spiking out a solution first, if I don't fully understand the algorithm, for example--but then I will often scrap it and re-write it with tests, which usually produces a more clear statement of the solution since I have already thought through it. From which follows my next point: of course writing tests, and TDD in particular, does not preclude thinking hard about your code's structure. But without experience testing, and especially doing TDD/BDD, I feel that it is very hard to understand the tradeoffs and challenges involved, as well as the pluses. So when I hear either a vehement denouncement or statement of support, I tend to suspect a lack of experience more than anything else. Although, I suppose Uncle Bob is a special case...