> If you follow TDD, you ensure the line of code is covered by writing the test first, ensuring it fails, then writing the line that makes it pass.<p>This isn't quite true. There are two ways to lose line coverage. The first is if new code duplicates a case that was previous caught elsewhere. For example, suppose current code handles n>=0, with a special where n=0 returns 0, and the new code handles n<=0 by returning 0.<p>It's not always clear when new code shadows the old code path, leaving it with under 100% coverage.<p>The other way is through refactoring. My usual example is to replace string search implementation using the naive O(n*m) algorithm with the KMP algorithm, keeping the API unchanged. The KMP machinery is more complicated, and it's unlikely that the tests used to drive the naive implementation will be enough to validate the refactor.<p>Following the "fear-driven development" methodology means adding more test until you're confident the refactor was valid. But this is "test last", and not part of TDD.<p>I'm much more an FDD practitioner than I am a TDD one. :) And the idea of live code coverage sounds great to me.