Code coverage plugin in Cypress - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Understanding code coverage report output

Given the following Cypress test and code coverage setup, what will be the coverage percentage reported for the function add after running the test?

Cypress

function add(a, b) {
  if (a === 0) {
    return b;
  }
  return a + b;
}

describe('add function', () => {
  it('returns b when a is zero', () => {
    expect(add(0, 5)).to.equal(5);
  });
});

A 50%

B 100%

C 0%

D 75%

💡 Hint

Think about which lines of the function are executed by the test.

The test only covers the if (a === 0) branch and returns b. The return a + b line is never executed, so only half of the function's lines are covered, resulting in 50% coverage.

❓ assertion

intermediate

Correct assertion for coverage threshold

Which assertion correctly checks that the global coverage object reports at least 80% statement coverage in Cypress tests?

Cypress

/* Assume global coverage object is available as window.__coverage__ */

A assert(window.__coverage__.statements >= 80);

B expect(window.__coverage__.statements.percent).to.be.above(80);

C expect(window.__coverage__.statements.pct).to.be.gte(80);

D expect(window.__coverage__.statements.pct).to.equal(80);

💡 Hint

Check the property name for statement coverage percentage in the coverage object.

The coverage object uses statements.pct to represent statement coverage percentage. Option C uses the correct property and assertion method to check if coverage is greater than or equal to 80.

🔧 Debug

advanced

Debugging missing coverage data

You configured Cypress with the code coverage plugin, but after running tests, the coverage report is empty. Which of the following is the most likely cause?

A The test files are missing the <code>describe</code> blocks.

B The <code>cy.visit()</code> command is missing in tests.

C The coverage report folder path is incorrect in <code>cypress.json</code>.

D The instrumented code is not loaded during tests.

💡 Hint

Think about what code coverage measures and what must happen for it to collect data.

Code coverage requires instrumented code to be loaded during tests. If the instrumented code is not loaded, coverage data will be empty. Missing describe blocks or cy.visit() may cause tests to fail but do not directly cause empty coverage. Incorrect folder path affects report saving but not data collection.

❓ framework

advanced

Configuring Cypress code coverage plugin

Which configuration snippet correctly sets up the Cypress code coverage plugin to collect coverage and generate reports after tests?

A

module.exports = {
  e2e: {
    setupNodeEvents(on, config) {
      require('cypress-plugin-code-coverage')(on, config);
      return config;
    }
  }
};

B

module.exports = {
  e2e: {
    setupNodeEvents(on, config) {
      require('@cypress/code-coverage/task')(on, config);
      return config;
    }
  }
};

C

module.exports = {
  e2e: {
    setupNodeEvents(on, config) {
      on('before:run', () => console.log('Starting tests'));
      return config;
    }
  }
};

D

module.exports = {
  e2e: {
    setupNodeEvents(on, config) {
      require('@cypress/code-coverage')(on, config);
      return config;
    }
  }
};

💡 Hint

Check the exact package name and method to register the coverage task.

The official Cypress code coverage plugin requires importing @cypress/code-coverage/task in setupNodeEvents. Option B correctly does this. Option B uses a wrong package name. Option B misses /task suffix. Option B does not register coverage.

🧠 Conceptual

expert

Impact of source maps on coverage accuracy

Why are source maps important when using the Cypress code coverage plugin with transpiled code (e.g., TypeScript or Babel)?

A They map the transpiled code back to original source lines, ensuring accurate coverage reporting.

B They speed up test execution by caching coverage data.

C They automatically fix syntax errors in the transpiled code.

D They enable Cypress to run tests in multiple browsers simultaneously.

💡 Hint

Think about how coverage tools relate executed code to original source code.

Source maps connect the transpiled code to the original source code lines. This allows the coverage plugin to report coverage accurately on the original files, not the transformed code. They do not affect speed, fix syntax errors, or enable parallel browser runs.

Practice

1. What is the main purpose of the Cypress code coverage plugin?

easy

A. To show which parts of your code are tested and which are not

B. To speed up test execution time

C. To automatically fix bugs in your code

D. To generate user interface screenshots

Solution

1. Step 1: Understand code coverage concept

   Code coverage helps identify which lines or branches of code are executed during tests.

2. Step 2: Match purpose with plugin function

   The Cypress code coverage plugin tracks and reports tested vs untested code parts.

3. Final Answer:

   To show which parts of your code are tested and which are not -> Option A

4. Quick Check:

   Code coverage = tested vs untested code [OK]

Hint: Code coverage = shows tested and missed code parts [OK]

Common Mistakes:

• Thinking it speeds up tests
• Believing it fixes bugs automatically
• Confusing it with screenshot tools

2. Which file should you modify to enable the Cypress code coverage plugin support?

easy

A. cypress/support/e2e.js

B. cypress/fixtures/data.json

C. package.json

D. cypress.config.js

Solution

1. Step 1: Identify where plugin support code goes

   The plugin support code is added in the support file to load before tests run.

2. Step 2: Choose correct support file path

   By default, Cypress uses cypress/support/e2e.js for test support setup.

3. Final Answer:

   cypress/support/e2e.js -> Option A

4. Quick Check:

   Support file = cypress/support/e2e.js [OK]

Hint: Support code goes in cypress/support/e2e.js [OK]

Common Mistakes:

• Modifying cypress.config.js only
• Changing package.json for plugin support
• Editing fixture files for plugin setup

3. Given this snippet in cypress/support/e2e.js:

import '@cypress/code-coverage/support';

What will happen when you run your tests?

medium

A. Tests will fail due to missing plugin installation

B. No effect; code coverage requires config changes only

C. Code coverage data will be collected during tests

D. Tests will run but coverage report will be empty

Solution

1. Step 1: Understand import statement effect

   Importing '@cypress/code-coverage/support' enables coverage collection hooks.

2. Step 2: Recognize plugin behavior during test run

   This import activates coverage tracking so data is gathered as tests run.

3. Final Answer:

   Code coverage data will be collected during tests -> Option C

4. Quick Check:

   Import support = coverage data collected [OK]

Hint: Importing support enables coverage collection [OK]

Common Mistakes:

• Assuming import alone fails tests
• Thinking config changes alone enable coverage
• Believing coverage report is empty without extra steps

4. You added the code coverage plugin but your coverage report is empty after tests run. What is the most likely cause?

medium

A. You did not write any tests

B. You forgot to instrument your app code with the coverage tool

C. You imported the plugin support file twice

D. You ran tests in headless mode

Solution

1. Step 1: Understand coverage instrumentation

   Coverage requires your app code to be instrumented to track executed lines.

2. Step 2: Identify missing instrumentation effect

   Without instrumentation, coverage plugin cannot detect which code ran, so report is empty.

3. Final Answer:

   You forgot to instrument your app code with the coverage tool -> Option B

4. Quick Check:

   Missing instrumentation = empty coverage report [OK]

Hint: Instrument app code to get coverage data [OK]

Common Mistakes:

• Assuming no tests means empty report
• Thinking duplicate imports cause empty report
• Believing headless mode disables coverage

5. You want to improve your test suite by using the Cypress code coverage plugin. Which steps should you follow to get a working coverage report? Select the correct sequence.

hard

A. Instrument app code, run tests, install plugin, import support in e2e.js, check report

B. Run tests, install plugin, import support in e2e.js, instrument app code, check report

C. Import support in e2e.js, run tests, install plugin, instrument app code, check report

D. Install plugin, instrument app code, import support in e2e.js, run tests, check report

Solution

1. Step 1: Install the code coverage plugin

   First, add the plugin package to your project dependencies.

2. Step 2: Instrument your application code

   Modify your app build to include coverage instrumentation for tracking.

3. Step 3: Import the plugin support file in cypress/support/e2e.js

   This enables coverage hooks during test execution.

4. Step 4: Run your Cypress tests

   Tests will now collect coverage data as they execute.

5. Step 5: Check the generated coverage report

   Review which code was covered and improve tests accordingly.

6. Final Answer:

   Install plugin, instrument app code, import support in e2e.js, run tests, check report -> Option D

7. Quick Check:

   Correct setup sequence = Install plugin, instrument app code, import support in e2e.js, run tests, check report [OK]

Hint: Install, instrument, import support, run tests, check report [OK]

Common Mistakes:

• Running tests before installing plugin
• Skipping instrumentation step
• Importing support after running tests