3 ms·

You are misusing the term, and the conflation around definitions of TDD make up half of every 'TDD flamefest'. http://c2.com/cgi/wiki?TestDrivenDevelopment htt

by keyist 16y ago

You are misusing the term, and the conflation around definitions of TDD make up half of every 'TDD flamefest'. http://c2.com/cgi/wiki?TestDrivenDevelopment http://c2.com/cgi/wiki?TestDrivenDevelopment TDD specifically calls not only for unit tests, but for writing them first, ie the test _drives_ the development. You write a test that fails, then write code to pass the test. One can be anti-TDD but still believe in unit tests, full coverage, etc.

silentbicycle 16y ago
Indeed. I've never seen a TDD debate that has focused specifically on whether tests upfront are sufficient for designing good APIs, etc., though (ironically, the most important part of TDD!). Usually, one side is aghast that the other side doesn't believe in testing (when they usually do, just not to an eXtreme), and the other isn't convinced that letting tests do all the design work makes sense. They're usually talking (or firing cannonballs!) past each other, mistaking disagreement for mutually extremist positions. (And then the "us vs. them" feelings kick in...) I'm in very strong agreement that automated testing (unit, regression, integration, etc.) pays for itself in most sufficiently large projects, but skeptical of TDD specifically - testing during exploratory programming often gives good feedback, but it's just one of many tools.
- c00p3r 16y ago
  Writing a test-cases based on business cases (domain knowledge) before any code is a good practice. It is that simple.
  - silentbicycle 16y ago
    I think it's better to have the spec be the code, as much as possible.
MartinCron 16y ago
I just wanted to throw in "test automation, yes!" without starting any controversy. Although I've been operating with a slightly different (and hopefully less controversial) TDD definition. Instead of getting all hung up on sequence and test-first, I ask "are you using automated tests as the primary way of executing your code as you're working on it". If the answer is yes, then at least that part of the code is test-driven. If the answer is no, then at least that part of the code is not test-driven. You can write the tests first all you want, but if you're not running them, often, and doing all of the "does this work" through the UI or the debugger, how test-driven are you really?
wariola 16y ago
Realizing that this post might just cause another flame out about unit testing, test-driven development (TDD) and policy-driven development I wanted to post what I think is a useful link about a platform that can assist you to "maintain" the human commitment to TDD: http://www.parasoft.com/jsp/products/article.jsp?articleId=3160 http://www.parasoft.com/jsp/products/article.jsp?articleId=3... Hope this helps.

by keyist 16y ago

silentbicycle 16y ago

Indeed. I've never seen a TDD debate that has focused specifically on whether tests upfront are sufficient for designing good APIs, etc., though (ironically, the most important part of TDD!). Usually, one side is aghast that the other side doesn't believe in testing (when they usually do, just not to an eXtreme), and the other isn't convinced that letting tests do all the design work makes sense. They're usually talking (or firing cannonballs!) past each other, mistaking disagreement for mutually extremist positions. (And then the "us vs. them" feelings kick in...) I'm in very strong agreement that automated testing (unit, regression, integration, etc.) pays for itself in most sufficiently large projects, but skeptical of TDD specifically - testing during exploratory programming often gives good feedback, but it's just one of many tools.

c00p3r 16y ago
Writing a test-cases based on business cases (domain knowledge) before any code is a good practice. It is that simple.
- silentbicycle 16y ago
  I think it's better to have the spec be the code, as much as possible.

MartinCron 16y ago

I just wanted to throw in "test automation, yes!" without starting any controversy. Although I've been operating with a slightly different (and hopefully less controversial) TDD definition. Instead of getting all hung up on sequence and test-first, I ask "are you using automated tests as the primary way of executing your code as you're working on it". If the answer is yes, then at least that part of the code is test-driven. If the answer is no, then at least that part of the code is not test-driven. You can write the tests first all you want, but if you're not running them, often, and doing all of the "does this work" through the UI or the debugger, how test-driven are you really?

wariola 16y ago

Realizing that this post might just cause another flame out about unit testing, test-driven development (TDD) and policy-driven development I wanted to post what I think is a useful link about a platform that can assist you to "maintain" the human commitment to TDD: http://www.parasoft.com/jsp/products/article.jsp?articleId=3160 http://www.parasoft.com/jsp/products/article.jsp?articleId=3... Hope this helps.