3 ms·

There are multiple studies (ref. Making Software, Oram & Wilson), the results are inconclusive. It's especially not clear whether it's worth it to do TDD in com

by blub 11y ago

There are multiple studies (ref. Making Software, Oram & Wilson), the results are inconclusive. It's especially not clear whether it's worth it to do TDD in comparison with simple automated testing and other testing strategies. You are preaching by the way.

pmarreck 11y ago
> Making Software, Oram & Wilson Going to quote one of the authors (Hakan Erdogmus) from here: https://computinged.wordpress.com/2010/11/01/making-software-tdd-doesnt-work-architecting-is-mixed-scripting-is-great/ https://computinged.wordpress.com/2010/11/01/making-software... "I am one of the authors of the TDD chapter. Ours was a review of existing some 30+ studies of TDD. Yes, Nachi’s experiments (the MSR study mentioned above) were included. BTW, I wouldn’t have concluded that “tdd doesn’t work” based on our data. Rather, I would have conservatively concluded: there is moderate evidence supporting TDD’s external quality and test-support benefits, but there is no consistent evidence in one direction or other regarding its productivity effects." The only thing inconclusive was the increased productivity effect, not the code quality effect. > It's especially not clear whether it's worth it to do TDD in comparison with simple automated testing and other testing strategies. https://www.researchgate.net/publication/3188484_On_the_effectiveness_of_the_test-first_approach_to_programming https://www.researchgate.net/publication/3188484_On_the_effe... I've done every testing strategy. Test-none, BDD, TDD, test-after, integration testing, unit testing, GUI testing, you name it. If your code will last longer than a couple years, it is worth it to do extensive unit testing via TDD, integration testing of major/important workflows, a visual once-over by a QA person to make sure something didn't break the CSS, and that's it. If you are the founder of a startup and expect to sell within 2 years (and are thus incentivized not to go the TDD route), you better be correct in your bet or there will be technical-debt hell to pay. > preaching Espousing something that I have found over and over again in my programming career (testing since about 2004, TDD since about 5 years ago) is now "preaching"? Call me a prophet, then. I know exactly what I see. Don't listen to me though, I've only been coding since I was 8 in 1980... I encourage you to find out for yourself.
- blub 11y ago
  I think you should go back and read that comment on the blog, because all statements are qualified e.g: "conservatively concluded", "moderate evidence". You on the other hand seem to be certain that it works. So certain that you're using no qualifiers, writing lengthy replies and selectively providing links that support your assertions. When pressed for information you provide a reasonable defense of unit-testing not TDD. Yes, I know unit-tests are nice when part of a testing strategy together with integration testing, UI testing, etc. I am not at all convinced that TDD is better and you haven't changed that. I am ignoring personal opinions and blog posts because too many software engineering practices are just popular rituals. TDD proponents need to prove conclusively that TDD is significantly better than selective test-after to offset the productivity loss, and they haven't done that.
  - pmarreck 11y ago
    "Moderate evidence" is still evidence. TDD forces your code to be tightly focused. It's very hard to write a test for reams of functionality before you write that functionality, so your code is automatically tight (and as a result, easier to refactor, maintain, understand, etc). I don't see how this is so hard to see or why you need empirical evidence for that part at least. A lot of what "value" is is quite subjective, even in programming. You know "good code" when you see it. Why don't you try TDD and form your own opinion?
    - blub 11y ago
      Yes, I will have to try it at some point. I've been postponing that due to lack of time and skepticism.

by blub 11y ago

pmarreck 11y ago

> Making Software, Oram & Wilson Going to quote one of the authors (Hakan Erdogmus) from here: https://computinged.wordpress.com/2010/11/01/making-software-tdd-doesnt-work-architecting-is-mixed-scripting-is-great/ https://computinged.wordpress.com/2010/11/01/making-software... "I am one of the authors of the TDD chapter. Ours was a review of existing some 30+ studies of TDD. Yes, Nachi’s experiments (the MSR study mentioned above) were included. BTW, I wouldn’t have concluded that “tdd doesn’t work” based on our data. Rather, I would have conservatively concluded: there is moderate evidence supporting TDD’s external quality and test-support benefits, but there is no consistent evidence in one direction or other regarding its productivity effects." The only thing inconclusive was the increased productivity effect, not the code quality effect. > It's especially not clear whether it's worth it to do TDD in comparison with simple automated testing and other testing strategies. https://www.researchgate.net/publication/3188484_On_the_effectiveness_of_the_test-first_approach_to_programming https://www.researchgate.net/publication/3188484_On_the_effe... I've done every testing strategy. Test-none, BDD, TDD, test-after, integration testing, unit testing, GUI testing, you name it. If your code will last longer than a couple years, it is worth it to do extensive unit testing via TDD, integration testing of major/important workflows, a visual once-over by a QA person to make sure something didn't break the CSS, and that's it. If you are the founder of a startup and expect to sell within 2 years (and are thus incentivized not to go the TDD route), you better be correct in your bet or there will be technical-debt hell to pay. > preaching Espousing something that I have found over and over again in my programming career (testing since about 2004, TDD since about 5 years ago) is now "preaching"? Call me a prophet, then. I know exactly what I see. Don't listen to me though, I've only been coding since I was 8 in 1980... I encourage you to find out for yourself.

blub 11y ago
I think you should go back and read that comment on the blog, because all statements are qualified e.g: "conservatively concluded", "moderate evidence". You on the other hand seem to be certain that it works. So certain that you're using no qualifiers, writing lengthy replies and selectively providing links that support your assertions. When pressed for information you provide a reasonable defense of unit-testing not TDD. Yes, I know unit-tests are nice when part of a testing strategy together with integration testing, UI testing, etc. I am not at all convinced that TDD is better and you haven't changed that. I am ignoring personal opinions and blog posts because too many software engineering practices are just popular rituals. TDD proponents need to prove conclusively that TDD is significantly better than selective test-after to offset the productivity loss, and they haven't done that.
- pmarreck 11y ago
  "Moderate evidence" is still evidence. TDD forces your code to be tightly focused. It's very hard to write a test for reams of functionality before you write that functionality, so your code is automatically tight (and as a result, easier to refactor, maintain, understand, etc). I don't see how this is so hard to see or why you need empirical evidence for that part at least. A lot of what "value" is is quite subjective, even in programming. You know "good code" when you see it. Why don't you try TDD and form your own opinion?
  - blub 11y ago
    Yes, I will have to try it at some point. I've been postponing that due to lack of time and skepticism.