Test Coverage Calculator

Line coverage: percentage of source lines executed during tests. Branch coverage: percentage of decision paths taken (both true/false for if/else). Function coverage: percentage of functions/methods that were called. Statement coverage: percentage of individual statements executed (finer-grained than line coverage). Branch coverage is generally the most meaningful because it catches logic gaps that line coverage misses.

80% is the widely accepted industry standard for most production projects. Google's engineering guidelines suggest 60% as acceptable, 75% as good, and 90%+ as exemplary. However, raw percentages can be misleading — 100% line coverage doesn't guarantee correct behavior. Aim for 80% as a starting point, focus on critical paths, and use meaningful assertions rather than just maximizing coverage numbers.

You need two numbers for each metric: total (how many exist in your codebase) and covered (how many were executed during your test suite). Jest and Vitest print these numbers when you run with --coverage: e.g., 'Lines: 450/600' means 450 covered out of 600 total. Enter these numbers directly into the calculator to see your percentage and pass/fail status.

In jest.config.js: add coverageThreshold: { global: { lines: 80, functions: 80, branches: 70, statements: 80 } }. In vitest.config.ts: add coverage: { thresholds: { lines: 80, functions: 80, branches: 70 } } inside the test block. The build will fail if any metric falls below its threshold — perfect for CI enforcement. This calculator generates the config snippet based on your entered values.

Because a line can be 'covered' even if only one branch was taken. For example, if (condition) { doA() } else { doB() } — if your tests only trigger the true branch, line coverage shows the if-statement as covered, but branch coverage shows 50% (one of two paths). Branch coverage is stricter and catches gaps in conditional logic that line coverage misses.

v8 uses Node.js's built-in V8 engine coverage data — it's fast, no code instrumentation needed, and works with source maps. Istanbul instruments your code by injecting counters at compile time — it's slower but generally more accurate for complex code, especially around branches in minified or transpiled code. For most TypeScript projects, v8 is sufficient and recommended. Use istanbul if you notice v8 misreporting edge cases.