Code coverage reports in Jenkins - Step-by-Step Execution

Process Flow - Code coverage reports

Start Jenkins Job

↓

Run Tests with Coverage

↓

Generate Coverage Report

↓

Publish Report in Jenkins

↓

View Coverage Results

↓

Decide on Code Quality

↓

End

The Jenkins job runs tests with coverage enabled, generates a report, publishes it, and then you view the results to check code quality.

Execution Sample

Jenkins

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        sh 'pytest --cov=./ --cov-report=xml'
      }
    }
    stage('Publish Coverage') {
      steps {
        publishCoverage adapters: [coberturaAdapter('coverage.xml')]
      }
    }
  }
}

This Jenkins pipeline runs tests with coverage and publishes the coverage report.

Process Table

Step	Action	Command/Tool	Result
1	Start Jenkins job	Jenkins	Job triggered and environment prepared
2	Run tests with coverage	pytest --cov=./ --cov-report=xml	Tests run, coverage data collected
3	Generate coverage report	pytest outputs coverage.xml	coverage.xml file created
4	Publish coverage report	publishCoverage with coberturaAdapter	Coverage report published in Jenkins UI
5	View coverage results	User views Jenkins coverage tab	Coverage percentages displayed
6	Decide on code quality	User reviews report	Decide to accept or improve code coverage

💡 All steps complete, coverage report available for review

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
coverage_data	none	collected during tests	saved in coverage.xml	published in Jenkins	available for viewing

Key Moments - 2 Insights

Why do we need to run tests with coverage enabled before generating the report?

Because coverage data is collected during test execution (see execution_table step 2). Without running tests, there is no data to generate a report.

What does the publishCoverage step do in Jenkins?

It takes the coverage report file (coverage.xml) and makes it visible in Jenkins UI (see execution_table step 4). This helps users see coverage results easily.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the coverage.xml file created?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Check the 'Generate coverage report' action in the execution_table

According to the variable tracker, when is coverage_data first collected?

A After Step 3

B After Step 1

C After Step 2

D After Step 4

💡 Hint

Look at coverage_data changes in variable_tracker after each step

If the publishCoverage step is skipped, what happens to the coverage report visibility?

A Report is still visible in Jenkins UI

B Report is generated but not visible in Jenkins UI

C Tests won't run

D Coverage data won't be collected

💡 Hint

Refer to execution_table step 4 about publishing coverage

Concept Snapshot

Jenkins Code Coverage Reports:
- Run tests with coverage enabled (e.g., pytest --cov)
- Coverage data saved in a report file (coverage.xml)
- Use publishCoverage step to show report in Jenkins UI
- View coverage results to assess code quality
- Helps ensure tests cover important code parts

Full Transcript

In Jenkins, code coverage reports are created by running tests with coverage enabled, which collects data about which parts of the code were tested. This data is saved in a file like coverage.xml. Then, Jenkins uses a publishCoverage step to display this report in its user interface. Users can view the coverage percentages and decide if the code quality is good or needs improvement. The process starts with triggering the Jenkins job, running tests, generating the report, publishing it, and finally viewing the results.

Practice

1. What is the main purpose of code coverage reports in Jenkins?

easy

A. To show which parts of the code are tested

B. To deploy the application automatically

C. To monitor server CPU usage

D. To manage user permissions

Solution

1. Step 1: Understand code coverage reports

   Code coverage reports indicate which parts of the source code have been executed during tests.

2. Step 2: Identify Jenkins role

   Jenkins uses these reports to help developers see test completeness and improve code quality.

3. Final Answer:

   To show which parts of the code are tested -> Option A

4. Quick Check:

   Code coverage = tested code parts [OK]

Hint: Coverage reports show tested code areas, not deployment [OK]

Common Mistakes:

• Confusing coverage with deployment
• Thinking coverage monitors server stats
• Mixing coverage with user management

2. Which Jenkins plugin is commonly used to publish Java code coverage reports?

easy

A. Git Plugin

B. JaCoCo Plugin

C. Docker Plugin

D. Slack Notification Plugin

Solution

1. Step 1: Identify coverage plugins for Java

   JaCoCo is a popular plugin for Java projects to generate code coverage reports in Jenkins.

2. Step 2: Exclude unrelated plugins

   Git manages source code, Docker manages containers, Slack sends messages, so they don't handle coverage.

3. Final Answer:

   JaCoCo Plugin -> Option B

4. Quick Check:

   Java coverage = JaCoCo [OK]

Hint: JaCoCo is the standard for Java coverage in Jenkins [OK]

Common Mistakes:

• Choosing Git for coverage
• Confusing Docker with coverage tools
• Selecting notification plugins

3. Given this Jenkins pipeline snippet, what will be the result of the jacoco step?

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        junit '**/test-results.xml'
        jacoco execPattern: '**/jacoco.exec'
      }
    }
  }
}

medium

A. Publishes JaCoCo coverage report using the specified exec file

B. Runs unit tests and skips coverage report

C. Fails because jacoco is not a valid step

D. Publishes test results but ignores coverage data

Solution

1. Step 1: Understand the jacoco step usage

   The jacoco step in Jenkins pipeline publishes coverage reports using the exec file pattern provided.

2. Step 2: Analyze the snippet

   The pipeline runs tests with junit and then publishes coverage with jacoco execPattern: '**/jacoco.exec'.

3. Final Answer:

   Publishes JaCoCo coverage report using the specified exec file -> Option A

4. Quick Check:

   jacoco step publishes coverage report [OK]

Hint: jacoco step publishes coverage from exec files [OK]

Common Mistakes:

• Thinking jacoco runs tests
• Assuming jacoco step is invalid
• Ignoring coverage data in pipeline

4. You added the JaCoCo plugin to Jenkins but the coverage report does not appear after the build. What is the most likely cause?

medium

A. The Jenkins server is offline

B. The Jenkins user lacks admin rights

C. The build script does not run any tests

D. The jacoco.exec file path is incorrect or missing

Solution

1. Step 1: Check coverage report prerequisites

   JaCoCo needs the jacoco.exec file generated by tests to publish coverage.

2. Step 2: Identify common error

   If the exec file path is wrong or the file is missing, Jenkins cannot show the coverage report.

3. Final Answer:

   The jacoco.exec file path is incorrect or missing -> Option D

4. Quick Check:

   Missing exec file = no coverage report [OK]

Hint: Check jacoco.exec file path if coverage missing [OK]

Common Mistakes:

• Blaming Jenkins offline status
• Ignoring test execution for coverage
• Assuming user rights block coverage display

5. You want Jenkins to fail the build if code coverage falls below 80%. Which configuration should you add to the JaCoCo plugin in your pipeline?

hard

A. jacoco(execPattern: '**/jacoco.exec', failBuildIfCoverageLow: 80)

B. jacoco(execPattern: '**/jacoco.exec', changeBuildStatus: true, minimumCoverage: 80)

C. jacoco(execPattern: '**/jacoco.exec', changeBuildStatus: true, minimumInstructionCoverage: 80)

D. jacoco(execPattern: '**/jacoco.exec', coverageThreshold: 80)

Solution

1. Step 1: Understand JaCoCo coverage thresholds

   The JaCoCo plugin uses minimumInstructionCoverage to set the minimum coverage percentage for instructions.

2. Step 2: Identify correct syntax to fail build

   Setting changeBuildStatus: true with minimumInstructionCoverage: 80 makes Jenkins fail if coverage is below 80%.

3. Final Answer:

   jacoco(execPattern: '**/jacoco.exec', changeBuildStatus: true, minimumInstructionCoverage: 80) -> Option C

4. Quick Check:

   minimumInstructionCoverage + changeBuildStatus = fail below threshold [OK]

Hint: Use minimumInstructionCoverage with changeBuildStatus true [OK]

Common Mistakes:

• Using non-existent parameters like coverageThreshold
• Omitting changeBuildStatus to fail build
• Confusing minimumCoverage with minimumInstructionCoverage