Hacker News Reader

Comment by tehwalrus | Hacker News Reader

TDD is good for verifying that your code handles the set of requirements given by the customer - including any edge cases that matter to them. I probably agree that 100% test passes doesn't equal no bugs.

Nonetheless, it's still useful! You can still write TD code and use your brain - it is only slightly easier to be lazy (and specifically, lazy in a way you're not supposed to care about, yet.)

In the end, production use crash reports will reveal any bugs that matter in the system (if any), and you can write new tests for those extra cases and make the code pass again. Combined with the rest of Agile (sorry,) i.e. fast release cycles and so on, this isn't a road block.

View on HN

> 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 =)).

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 ?

> 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).

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.

Reply on news.ycombinator.com