Generating Code Coverage Reports in Dart
Code coverage shows which lines your tests execute. It's a health check for your test suite's reach, not a measure of code quality. Use the coverage package to generate reports for CI/CD. The footgun is that high coverage doesn't prove correctness.
Why it exists
To answer the question, "How much of my code is actually being tested?" Without coverage reports, developers can't easily identify untested logic, leading to blind spots where bugs can hide. It provides a quantitative, automated way to measure test reach.
The mental model
Think of code coverage as shining a UV light on your codebase after your tests have run. The lines that glow are the ones your tests touched. The dark spots are areas your tests missed entirely. It shows you where your tests went, but not how well they checked things when they were there.
How it works
The process has two stages. First, you run your tests with specific Dart VM flags (--enable-vm-service) that open a service port. The collect_coverage tool connects to this port, inspects which lines of code were executed, and saves this raw data to a coverage.json file. Second, the format_coverage tool reads this JSON and converts it into a standard format like LCOV (lcov.info). The coverage package provides a convenient script, test_with_coverage, that automates this entire sequence.
When to use it
Use coverage reports in your CI/CD pipeline to enforce a minimum testing threshold and prevent merging untested code. Locally, use an IDE extension to visualize which lines are missing coverage as you code. It is also effective for identifying dead or unreachable code that could be removed.
When not to use it
Do not use coverage percentage as the sole metric for code quality or developer performance. A test that runs a line but has no expect assertion still increases coverage but provides zero validation. Chasing 100% on trivial code (like simple data classes) is often a waste of effort. The default setup may also require manual configuration for complex monorepo workspaces.
One canonical example
The simplest way to generate a report is to run dart pub global run coverage:test_with_coverage from your project's root. This command automatically runs all tests, collects data, and generates two files in a new coverage/ directory: coverage.json (the raw data) and lcov.info (the formatted report for other tools to consume).
Interview question
What is the primary benefit of using code coverage reports in a Dart project?
- a.It guarantees that all tested code paths are free of bugs.
- b.It provides a quantitative measure of how much of the codebase is exercised by tests.Correct
- c.It serves as the sole reliable metric for overall code quality and developer performance.
- d.It automatically optimizes test execution speed by identifying slow tests.
Why? this is the answer
The card states that code coverage shows "which lines your tests execute" and is a "measure of test reach," directly supporting option B. It explicitly warns against using coverage as the "sole metric for code quality" and notes that "high coverage doesn't prove correctness," making options A and D incorrect.
Just read this? Test yourself on what you have been reading.
Read the original → pub.dev
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on dart — each one lists the topics its interview covers.
See open roles