4 ms·

That's the best point made yet - use TDD only if it's appropriate.

Klinky 12y ago
When it's appropriate is not always clear. Those drinking the Kool-Aid will probably say you should always use it. Probably the biggest sticking point for me is not knowing how your program should be structured ahead of time. You'll have trial and error along with plenty of refactoring, as you grapple with how the solution best fits the infrastructure you are writing for. Adding the overhead of writing tests for code/apis that are likely to change sounds like wasted effort. The fragmentation between different testing frameworks also doesn't help, with each having their own learning curve. Maybe people should focus on coding a minimum viable product, then revisit it after they understand better how their product should work in the infrastructure they are using. They will then have a better understanding of the tests they should write. The tests would likely come in handy as their program matures, and errors/downtime to their users becomes a bigger issue than pushing a product out the door.
wpietri 12y ago
I think there are a lot of things whose appropriateness is hard to know unless you have some experience with it. That's especially true where you're trading short-term costs for long-term wins. For example, think of restaurant hygiene. Safe food handling is hard work. And if you skimp on it, it's easy to say, "Hey, doing X isn't really necessary; nothing bad happened." For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear. I agree people should use it when appropriate; there are definitely times when I don't bother. But I'm concerned that people who haven't experienced success (and failure) with TDD will have poor intuition for when it's appropriate.
- greenyoda 12y ago
  "For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear." The ability to refactor without fear comes from having adequate test coverage. Whether you write the tests before you write the code (TDD) or after the code is completed doesn't seem to affect your ability to refactor at a later date.
  - wpietri 12y ago
    For me, it definitely affects the quality of the tests. Once I've written the production code, I know how it works, so its faults are harder for me to see. I also find it's easier to leave coverage gaps. I think I could get some of the same benefit by bringing in somebody else to review tests without looking at the production implementation, but I haven't tried. The other thing I think TDD gets for me is cleaner API design, because my orientation begins (and mainly stays) outside the thing I'm working on. And cleaner design definitely makes refactoring easier. Of course, if people have tried it both ways and feel they are getting the same results with some other technique, that's great. But one can only measure long-term maintainability by maintaining a code base for a while, so I think regardless my point on needing experience to judge appropriateness of TDD stands.

When it's appropriate is not always clear. Those drinking the Kool-Aid will probably say you should always use it. Probably the biggest sticking point for me is not knowing how your program should be structured ahead of time. You'll have trial and error along with plenty of refactoring, as you grapple with how the solution best fits the infrastructure you are writing for. Adding the overhead of writing tests for code/apis that are likely to change sounds like wasted effort. The fragmentation between different testing frameworks also doesn't help, with each having their own learning curve. Maybe people should focus on coding a minimum viable product, then revisit it after they understand better how their product should work in the infrastructure they are using. They will then have a better understanding of the tests they should write. The tests would likely come in handy as their program matures, and errors/downtime to their users becomes a bigger issue than pushing a product out the door.

wpietri 12y ago

I think there are a lot of things whose appropriateness is hard to know unless you have some experience with it. That's especially true where you're trading short-term costs for long-term wins. For example, think of restaurant hygiene. Safe food handling is hard work. And if you skimp on it, it's easy to say, "Hey, doing X isn't really necessary; nothing bad happened." For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear. I agree people should use it when appropriate; there are definitely times when I don't bother. But I'm concerned that people who haven't experienced success (and failure) with TDD will have poor intuition for when it's appropriate.

greenyoda 12y ago
"For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear." The ability to refactor without fear comes from having adequate test coverage. Whether you write the tests before you write the code (TDD) or after the code is completed doesn't seem to affect your ability to refactor at a later date.
- wpietri 12y ago
  For me, it definitely affects the quality of the tests. Once I've written the production code, I know how it works, so its faults are harder for me to see. I also find it's easier to leave coverage gaps. I think I could get some of the same benefit by bringing in somebody else to review tests without looking at the production implementation, but I haven't tried. The other thing I think TDD gets for me is cleaner API design, because my orientation begins (and mainly stays) outside the thing I'm working on. And cleaner design definitely makes refactoring easier. Of course, if people have tried it both ways and feel they are getting the same results with some other technique, that's great. But one can only measure long-term maintainability by maintaining a code base for a while, so I think regardless my point on needing experience to judge appropriateness of TDD stands.