Note on code coverage
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
This lesson preview is part of the Pain Free Mocking with Jest course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to Pain Free Mocking with Jest, plus 70+ \newline books, guides and courses with the \newline Pro subscription.
[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.