Lesson257 words

Code coverage analysis

Implement code coverage analysis

Publishing coverage

yaml
- task: PublishCodeCoverageResults@2 inputs: summaryFileLocation: '$(System.DefaultWorkingDirectory)/**/coverage.cobertura.xml'

Tests or a coverage tool must generate the summary file first. PublishCodeCoverageResults@2 accepts the minimatch path, merges matching summaries, and publishes the report. Cobertura and JaCoCo are coverage-format examples; v2 also accepts .coverage, .covx, .covb, .cjson, XML, LCOV, pycov, and other supported formats. JUnit, NUnit, VSTest, xUnit, and CTest are instead test-result formats.

What coverage does and does not tell you

Coverage measures which code executed while tests ran. It does not measure whether intended functional behaviour was verified. A high percentage therefore does not, by itself, establish good functionality coverage.

So treat coverage as a signal about untested regions, not as a quality score:

SignalWhat it establishes
Uncovered pathsCode that did not execute during the measured tests
Full coverageCoverage measured across the codebase
Azure Repos PR diff coverageCoverage of new or modified executable lines in that pull request
High percentageExecution evidence, not proof of good functional verification

Gating on it

For Azure Repos pull requests, publishing coverage posts a {pipeline-name}/codecoverage status for changed lines. Configure coverage.status.diff.target in a root azurepipelines-coverage.yml file; the default target is 70%. The status is advisory until it is configured as a required branch policy, which is what makes failure block the merge. Pull-request comments are optional.

Primary sources

Ready to study Designing and Implementing Microsoft DevOps Solutions (AZ-400)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free