Note on code coverage

[00:00 - 00:13] When starting out with testing, many developers set a goal of achieving 100% code coverage. What doesn't realize is that complete coverage is really attainable, nor should it be the sole metric of quality.

[00:14 - 01:23] When I worked as a learning facilitator at the last coding bootcamp, I usually saw a spiraling software engineers strive to achieve 100% code coverage. While I appreciate the zeal to get better, I honestly give feedback that this is not a good metric. Here's why. Code coverage alone doesn't tell the whole story. It only represents how much of our codebase is touched by tests, not how well those cases are validated. Having coverage on every line doesn't guarantee the absence of bugs either, as edge cases may remain untested . And as a program grows larger, the number of possible paths through the code expands exponentially. It quickly becomes infeasible to examine every single combination of inputs and conditional branches across all our methods. Significant efforts will be wasted aiming for coverage that provides limited, real value. Most experts recommend focusing coverage above 80% for critical parts of the application.

[01:24 - 01:35] The priority should be on thoroughly testing core business logic over and it's begin the last few percentage points.