4 ms·

Translation: "I don't understand TDD." I like how he links to the Wikipedia article on Horse Tack, but doesn't bother to back up any of his claims.

sho 17y ago
Isn't that a "no real scotsman" argument? Anyway, what's there to understand? TDD plainly means writing tests before writing the implementation, and he's railing against the whole concept. One also wonders how, or by whom, you might wish his argument to be "backed up". A compelling argument should stand or fall on its own merits.
- zacharydanger 17y ago
  How about his mentions of evidence to the contrary being backed up by actual evidence to the contrary. Or the speculative weaker points like, "TDD wrecks time estimates", "inefficiency", and "scope creep". Heck, in "Tests solve problems that don't exist" he sidesteps right past the real problem that TDD solves: refactoring code without inadvertently breaking something else. So yeah, "No true Scotsman" would ever rail against TDD without proper evidence.
  - blasdel 17y ago
    TDD doesn't help prevent breaking things when refactoring, automated testing does In that section he's complaining specifically about the type of tests that TDD results in -- that they strongly tend to test for totally unrealistic bugs, structural crap that would only possibly come up when writing the code from scratch. He's not anti-test, he's anti-test-first.
    - silentbicycle 17y ago
      I think a lot of people do what zach did, though - because of hype, perhaps, they're loose with terminology and conflate TDD with automated testing in general. Then, people argue until they're blue in the face, because they're talking about completely different things. (This happens with OO all the time.)
      - sho 17y ago
        Yeah, very true, especially with things like Rails where the community is somewhat .. faddish. Someone whose first real exposure to programming was Rails - and there are a lot of such people, coming from other web development areas - might well confuse TDD with automated testing itself. The two are taught/preached as one and the same.
        bphogan 17y ago
        The Rails community does tend to be a bit more interested in the "new shiny", but the heavy weight placed on testing has done wonders for improving the quality of the work I do. As for automated testing and TDD being considered one in the same, I believe there's a strong argument to suggest that they are. Allow me to explain. When I am coaching, mentoring, or training people, I have no problem with bringing up both TDD and automated testing at the same time. * We write a failing test * We then fire up the automated test runner * We make changes to our code until the test passes * We repeat, adding new tests. I can show that our automated test runner catches anything we do wrong immediately. I don't believe you get the full benefits of TDD if you don't automate the process, and you can't have automated testing without good tests. I used to write lots of code without tests and I paid the price - lots of wasted time tracking down bugs, delayed releases because I could't figure out why my new feature broke old stuff, the usual stuff. Investing time and energy learning how it's supposed to work has been the most valuable thing I've ever done for myself, my clients, and my company. The process I teach others is the process that I learned, and I feel that we're all much happier developers for it. I just want to come back to the point I made earlier... a lot of the people who evangelize this stuff believe in it not because it's "cool", but because it has actually saved us and our projects. If you want to separate the hype machines from the true believers, ask one to show you. The ones who believe in it will almost certainly devote their time to show you how they do it. I know I would.
        silentbicycle 17y ago
        I agree with you that it can be an excellent way to develop, but in some languages the same testing-as-you-go is typically handled by the type system or other tools instead* . While I'm quite convinced of the value of automated testing, TDD is just one method, and one better suited to e.g. Ruby than languages like OCaml. (This is sometimes lost on its most vocal proponents.) In all fairness, the language about type systems is often impenetrably mathematical, so I'm not surprised that the parallel isn't clear. (I really like OCaml, so I tried reading _The Definition of Standard ML_ to get a better understanding of the language family. Wham, brick wall. Then again, I'm not a mathematics grad student...I studied history.) * Which is just a different way of communicating semantic constraints ("this is never null", "this list always has at least two unique UTF-8 string values", "this can only be used on writable files", etc.) to the language and having them automatically checked.

sho 17y ago

Isn't that a "no real scotsman" argument? Anyway, what's there to understand? TDD plainly means writing tests before writing the implementation, and he's railing against the whole concept. One also wonders how, or by whom, you might wish his argument to be "backed up". A compelling argument should stand or fall on its own merits.

zacharydanger 17y ago
How about his mentions of evidence to the contrary being backed up by actual evidence to the contrary. Or the speculative weaker points like, "TDD wrecks time estimates", "inefficiency", and "scope creep". Heck, in "Tests solve problems that don't exist" he sidesteps right past the real problem that TDD solves: refactoring code without inadvertently breaking something else. So yeah, "No true Scotsman" would ever rail against TDD without proper evidence.
- blasdel 17y ago
  TDD doesn't help prevent breaking things when refactoring, automated testing does In that section he's complaining specifically about the type of tests that TDD results in -- that they strongly tend to test for totally unrealistic bugs, structural crap that would only possibly come up when writing the code from scratch. He's not anti-test, he's anti-test-first.
  - silentbicycle 17y ago
    I think a lot of people do what zach did, though - because of hype, perhaps, they're loose with terminology and conflate TDD with automated testing in general. Then, people argue until they're blue in the face, because they're talking about completely different things. (This happens with OO all the time.)
    - sho 17y ago
      Yeah, very true, especially with things like Rails where the community is somewhat .. faddish. Someone whose first real exposure to programming was Rails - and there are a lot of such people, coming from other web development areas - might well confuse TDD with automated testing itself. The two are taught/preached as one and the same.
      - bphogan 17y ago
        The Rails community does tend to be a bit more interested in the "new shiny", but the heavy weight placed on testing has done wonders for improving the quality of the work I do. As for automated testing and TDD being considered one in the same, I believe there's a strong argument to suggest that they are. Allow me to explain. When I am coaching, mentoring, or training people, I have no problem with bringing up both TDD and automated testing at the same time. * We write a failing test * We then fire up the automated test runner * We make changes to our code until the test passes * We repeat, adding new tests. I can show that our automated test runner catches anything we do wrong immediately. I don't believe you get the full benefits of TDD if you don't automate the process, and you can't have automated testing without good tests. I used to write lots of code without tests and I paid the price - lots of wasted time tracking down bugs, delayed releases because I could't figure out why my new feature broke old stuff, the usual stuff. Investing time and energy learning how it's supposed to work has been the most valuable thing I've ever done for myself, my clients, and my company. The process I teach others is the process that I learned, and I feel that we're all much happier developers for it. I just want to come back to the point I made earlier... a lot of the people who evangelize this stuff believe in it not because it's "cool", but because it has actually saved us and our projects. If you want to separate the hype machines from the true believers, ask one to show you. The ones who believe in it will almost certainly devote their time to show you how they do it. I know I would.
        silentbicycle 17y ago
        I agree with you that it can be an excellent way to develop, but in some languages the same testing-as-you-go is typically handled by the type system or other tools instead* . While I'm quite convinced of the value of automated testing, TDD is just one method, and one better suited to e.g. Ruby than languages like OCaml. (This is sometimes lost on its most vocal proponents.) In all fairness, the language about type systems is often impenetrably mathematical, so I'm not surprised that the parallel isn't clear. (I really like OCaml, so I tried reading _The Definition of Standard ML_ to get a better understanding of the language family. Wham, brick wall. Then again, I'm not a mathematics grad student...I studied history.) * Which is just a different way of communicating semantic constraints ("this is never null", "this list always has at least two unique UTF-8 string values", "this can only be used on writable files", etc.) to the language and having them automatically checked.