Hacker News new | ask | show | jobs
by jasonlotito 4837 days ago
> I probably agree that 100% test passes doesn't equal no bugs.

TDD never promised that, and practitioners of TDD understand that 100% coverage doesn't mean you won't have bugs. This doesn't invalidate the TDD or testing (as you are obviously aware of =)).
1 comments
taligent 4837 days ago
Sure you will still have bugs. The question is whether the reduction in bugs due to TDD outweighs the increased investment in developer and tester time.

Because for those of us who do TDD every day the blowout in time is at minimum 2-3x longer than without it. Not to mention the detrimental impact on build times.

All of that aside. Have you noticed how there are no decent metrics available for TDD's effectiveness ?

link
jasonlotito 4837 days ago
> Because for those of us who do TDD every day the blowout in time is at minimum 2-3x longer than without it.

I do not know your environment, but TDD does not add 2-3x longer for most everyone I know that practice it. This is especially true when you factor in total development time. Most estimates I see place TDD making the project take 15-30% longer.

> All of that aside. Have you noticed how there are no decent metrics available for TDD's effectiveness ?

Not sure what you mean by that. There are metrics you can use (how else could they do studies on this?). It's been proven time and time again in studies (some are linked in these threads here).

link
Silhouette 4837 days ago
It's been proven time and time again in studies (some are linked in these threads here).

I see that claim a lot, but when I look at the "studies" being cited, they rarely stand up to even cursory scrutiny about their methodology and the choice of test subjects.

These studies (or those making a case for TDD based on them) tend to do things like generalising results based on a few undergraduate students writing toy programs to draw conclusions about professional software developers working on industrial-scale applications, or using no unit testing at all as a control rather than say doing either test-first or test-last unit testing but not following the TDD process.

If you have better sources, please do share them. Developing a non-trivial application using two different techniques is rarely cost-effective, even without controlling for having different developers or experience in the two cases, so getting good quality data about the effectiveness of software engineering processes is hard.

link