Code coverage
The percentage of your code that actually runs while the tests run. It proves the tests touched the code, not that they checked anything.
See it
What it is
Coverage instruments your code, runs the suite, and reports which lines executed. It comes in flavors of increasing honesty: statement and line coverage (did this line run), function coverage (was this function entered), and branch coverage (did both sides of every if, ternary, and short-circuit run). Branch is the one worth reading. Tools: Istanbul and V8 coverage under the hood, surfaced by 'vitest run --coverage', 'jest --coverage', or 'go test -cover'.
Coverage is best used as a map, not a score. Sort the report by lowest coverage and you get a ranked list of code nobody has ever exercised, which is where the scary bugs live. It is also useful as a ratchet in CI: block changes that drop coverage on the files a pull request touches, rather than demanding a global number.
The misconception worth naming: coverage measures execution, not verification. A test that calls a function and asserts nothing at all scores 100%. Chasing a number produces exactly those tests, plus worthless tests for getters and config files. If you want to know whether your tests would actually catch a bug, mutation testing answers that question and coverage never will.
Ask AI for it
Set up code coverage for this project and report it usefully. Configure the test runner's coverage provider (vitest --coverage with v8, or jest --coverage with Istanbul), emit both a text summary for the terminal and an lcov/html report, and exclude config files, type definitions, generated code, and test files from the totals. Set thresholds on branch coverage rather than lines, and list the five least-covered source files with a one-line note on what an untested branch in each one would break.