

Visualize code coverage as you write your code - justinlilly
https://justin.abrah.ms/js/real-time-code-coverage-analysis.html

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

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.

It's not always clear when new code shadows the old code path, leaving it with
under 100% coverage.

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.

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.

I'm much more an FDD practitioner than I am a TDD one. :) And the idea of live
code coverage sounds great to me.

