New Code Coverage Check
Find out whether your pull request will pass the "Coverage on New Code ≥ 80%" quality gate before you push. You don't wait for the scan on the PR, and you don't push again to fix coverage.
The extension runs your unit tests with coverage and looks only at the lines you added or changed compared with the branch your PR goes into. It uses the same formula SonarQube uses, and highlights every new line that no test reaches.
How to use it
Click Check Coverage in the status bar (bottom of VS Code), or run New Code Coverage: Check New Code Coverage from the Command Palette (Ctrl+Shift+P).
- Run tests, then check, or Use latest coverage report if you just ran them.
- A pop-up shows the result:
Coverage on new code: 85.4%. Passes the 80% quality gate.Coverage on new code: 72.7%. Fails the 80% quality gate: 1 new line(s) and 2 condition(s) not covered.
- The status bar keeps the result:
✔ New code coverage 85.4% or ✖ New code coverage 72.7% (needs 80%) in red.
- Your changed lines are marked in the editor:
- red: new line not covered by any test
- yellow: new line covered, but not every branch (
if/else, &&, ||, ? :)
- green: covered
- Show Uncovered Lines lists each changed file with its percentage. Pick a file to jump to its first uncovered line.
Add tests, click Run Tests Again, and repeat until it passes.
Reads each repo's scan settings
You don't set anything up per repository. For whichever repo you check, the extension reads the SonarQube settings in its GitHub workflow files (.github/workflows/*.yml), sonar-project.properties and pom.xml, and applies them the same way the scan does:
| Scan setting |
What the extension does with it |
sonar.coverage.exclusions, sonar.exclusions |
Skips those files |
sonar.inclusions |
Counts only those files |
sonar.sources, sonar.tests, sonar.test.inclusions |
Counts only production code; test files are skipped |
sonar.projectBaseDir |
Resolves all of the above from that folder |
sonar.coverage.jacoco.xmlReportPaths |
Reads the coverage report from exactly that path, and runs the tests in that project's folder |
sonar.javascript.lcov.reportPaths |
Also checks JavaScript/TypeScript files, when that report exists |
If a workflow runs more than one scan, for example one per project, each scan step is kept separate. The extension uses the one whose folders contain your changed files. The New Code Coverage output shows which workflow step it used and the settings it applied.
The 80% threshold is part of the SonarQube server's quality gate and isn't in the workflow, so it comes from the threshold setting.
What counts as new code
- Lines added or changed on your branch since it split from the base branch, plus your uncommitted and untracked changes. You can check before you even commit.
- Base branch: for
feature/<workstream>/… branches (including csr12345/feature/<workstream>/pbi654321) it's workstream/<workstream>, or fixit/<workstream> if that's the only one. Otherwise you pick the branch, or set newCodeCoverage.baseBranch.
- Only production source files count (
.java by default). Test files and anything the scan excludes are skipped (see above).
- Comments, blank lines and declarations don't count, the same as in SonarQube.
Coverage = (covered new lines + covered new conditions) / (new lines to cover + new conditions)
This is SonarQube's "Coverage on New Code". Changes with fewer than 20 new lines are flagged as a small change, because SonarQube usually doesn't apply the coverage condition to those.
Running tests
| Project |
What runs |
Maven (pom.xml) |
mvn test with JaCoCo added on the command line. No pom.xml changes needed. Uses mvnw if the repo has it. |
| Project in a subfolder |
Found automatically. The folder comes from the scanner's sonar.coverage.jacoco.xmlReportPaths in your GitHub workflow, or from the shallowest pom.xml. If several folders are equally likely, you pick one once. |
| Gradle |
gradle test jacocoTestReport (the project needs the jacoco plugin) |
| Anything else |
Set newCodeCoverage.testCommand to a command that writes a JaCoCo XML or LCOV report |
Tests run in a VS Code terminal so you can watch them. A failing test doesn't stop the check. You're asked whether to continue with the report that was produced.
Settings
| Setting |
Default |
Description |
newCodeCoverage.threshold |
80 |
Required coverage on new code (%) |
newCodeCoverage.smallChangeLines |
20 |
Below this many new lines, a miss is shown as a warning instead of a failure (0 = off) |
newCodeCoverage.baseBranch |
(empty) |
Branch to compare with, if not worked out from the branch name |
newCodeCoverage.testCommand |
(empty) |
Custom test command |
newCodeCoverage.reportPaths |
JaCoCo and LCOV defaults |
Where coverage reports are found |
newCodeCoverage.sourceExtensions |
[".java"] |
File types that count toward coverage |
newCodeCoverage.exclusions |
test folders and *Test.java |
Files that don't count |
newCodeCoverage.useSonarExclusions |
true |
Use each repo's scan settings (see above) |
newCodeCoverage.highlightCovered |
true |
Show green bars on covered new lines |
Good to know
- Results can differ slightly from the server if its scan uses different exclusions or a different set of tests (for example, integration tests).
- If you edit a file after checking, its highlights are hidden until you check again.
- New Code Coverage in the Output panel shows the full details of each check.
Privacy
Everything runs on your computer. The extension reads your Git history and coverage reports and sends nothing anywhere.
