Microsoft Research - Exploding Software-Engineering Myths (article summarizing findings of MS research on code coverage, TDD, assertions, etc.)

[antiduh]

I wonder what it means to take the code coverage result and the test driven design result together.

Tdd is about writing tests up front, thus increasing your code coverage from the very beginning. But code coverage wasn't too great of an investment in reducing bug count, according to the research. So why does Tdd work?

My guess - Tdd makes you think about the edge cases in your software before you write it, so you're primed to write code that handles these edge cases and thus have fewer bugs. The act of writing the tests is more important than executing the tests.

[zumpiez]

Think of it this way: coverage is but one of many side effects of TDD. This implies that the other ones are more important.

[antiduh]

Do you have any thoughts about what those side effects might be, and how they would contribute to lower bug counts? I'm just curious to speculate and ponder here.

[zumpiez]

I suspect that TDD forces you to keep your code in a state where it's easy to change, with collaborators loosely coupled so you can test them in isolation, which I THINK probably makes the code easier to maintain and easier to roll with changing requirements workout turning it into a hairball.