agentsclimarketplace
Sign in

Dart test coverage

Skill kevmoo/dash_skills/skills/dart-test-coverage

Understand and improve test coverage in a Dart package. Helps agents run coverage, interpret results, and identify missed lines.From its SKILL.md

Install
npx -y skills add kevmoo/dash_skills --skill dart-test-coverage

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • runs commandsInstructs the agent to run 4 commands, including `dart test --coverage=.dart_tool/coverage` and 3 more.

SKILL.md

3.5 KB, 774 tokens by cl100k_base, as published. Nobody here has run it

Dart Test Coverage

Guidelines for running and interpreting test coverage in Dart packages.

When to use this skill

  • When asked to "check test coverage" or "improve coverage".
  • When you need to identify which parts of a library are untested.

Discovery

To find areas lacking test coverage:

Run Coverage Analysis

Follow the workflow to generate and interpret coverage data:

  1. Run Tests with Coverage: dart test --coverage=.dart_tool/coverage
  2. Interpret Results: Use the script or format_coverage as described in the Interpreting Results section to identify specific files and missed lines.

How to use this skill (The Workflow)

  1. Ensure tests pass by running dart test.
  2. Collect coverage by running dart test --coverage=.dart_tool/coverage.
  3. Interpret the results using the provided script or standard tools.
  4. Add tests to cover missed lines.

Running Coverage

Run the following command to collect coverage in JSON format:

dart test --coverage=.dart_tool/coverage

[!NOTE] We use .dart_tool/coverage as the output directory because .dart_tool is typically already ignored in .gitignore files.

[!TIP] For projects with complex conditional logic, you can pass the --branch-coverage flag to dart test to collect branch-level coverage.

Interpreting Results

Option 1: Use the custom interpreter script

This repository includes a zero-dependency script that parses the raw JSON output and provides a summary of covered percentage and missed lines.

Run it from the project root (adjust path to script as needed):

dart run skills/dart-test-coverage/scripts/interpret_coverage.dart .dart_tool/coverage <package_name>

Replace <package_name> with the name from pubspec.yaml.

Example Output:

package:my_pkg/src/file.dart: 50.0% (2/4 lines)
  Missed lines: 3, 4

Option 2: Use package:coverage

If package:test is installed, package:coverage is likely available as a transitive dependency. You can use its format_coverage tool.

To get a human-readable "pretty print" of the coverage:

dart run coverage:format_coverage --in=.dart_tool/coverage --out=stdout --pretty-print --report-on=lib

This will output the file content with hit counts on the left (e.g., 0| for missed lines).

Best Practices for Reporting Results

When presenting coverage results to the user, follow these guidelines:

  1. State the high-level percentage first to give immediate context.
  2. Identify specific files and missed lines clearly.
  3. Translate line numbers to code: Don't just say "lines 3-6 are missed". Look at the source file and tell the user which functions or blocks are untested (e.g., "The divide function is missing coverage").
  4. Propose concrete fixes: Provide example test code that the user can immediately apply to cover the missed lines.
  5. Use tables for multi-file summaries: When reporting on multiple files, use a markdown table with columns for File, Coverage %, and Missed Lines to make the summary easy to scan.

Constraints

  • ALWAYS verify that tests pass before collecting coverage.
  • DO NOT commit the .dart_tool/coverage directory.
  • Focus coverage improvements on lib/ files, not test/ or generated files.

What ships with it: 6 files

6.0 KB alongside SKILL.md

example/

scripts/

Gives 0 of the 12 instructions most test skills give in 774 tokens

Counted across 1,201 of the 2,096 authors here whose files we hold, read 2026-09-06

  • Write a failing test before writing codein 43 of 1201, across 36 files
  • Run the full test suitein 36 of 1201, across 35 files
  • Test only one variable per experimentin 34 of 1201, across 17 files
  • Read product marketing context before asking questionsin 34 of 1201, across 14 files
  • Mock external dependenciesin 34 of 1201, across 30 files
  • Define primary, secondary, and guardrail metricsin 33 of 1201, across 16 files
  • Pre-determine sample size before startingin 31 of 1201, across 14 files
  • Test behavior rather than implementationin 31 of 1201, across 29 files
  • Formulate a hypothesis before designing a testin 30 of 1201, across 13 files
  • Document every test hypothesis, variant, and resultin 29 of 1201, across 11 files
  • Use descriptive test function namesin 25 of 1201, across 21 files
  • Commit to the methodology without stopping earlyin 24 of 1201, across 8 files

Said here and by no other author read

  • Run tests with coverage flag
  • Interpret coverage results using provided tools
  • Identify specific files and missed lines
  • Translate missed line numbers to code blocks
  • Propose concrete test code fixes
  • Use markdown tables for multi-file summaries

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.