dart-test-coverage
installsforks
How to install dart-test-coverage?
kevmoo/dash_skills/dart-test-coverage
$npx -y skills add kevmoo/dash_skills --skill dart-test-coverageUnderstand and improve test coverage in a Dart package. Helps agents run coverage, interpret results, and identify missed lines.
SKILL.md
| 1 | # Dart Test Coverage |
| 2 | |
| 3 | Guidelines for running and interpreting test coverage in Dart packages. |
| 4 | |
| 5 | ## When to use this skill |
| 6 | - When asked to "check test coverage" or "improve coverage". |
| 7 | - When you need to identify which parts of a library are untested. |
| 8 | |
| 9 | ## Discovery |
| 10 | |
| 11 | To find areas lacking test coverage: |
| 12 | |
| 13 | ### Run Coverage Analysis |
| 14 | Follow the workflow to generate and interpret coverage data: |
| 15 | 1. **Run Tests with Coverage**: `dart test --coverage=.dart_tool/coverage` |
| 16 | 2. **Interpret Results**: Use the script or `format_coverage` as described in |
| 17 | the **Interpreting Results** section to identify specific files and missed |
| 18 | lines. |
| 19 | |
| 20 | ## How to use this skill (The Workflow) |
| 21 | 1. Ensure tests pass by running `dart test`. |
| 22 | 2. Collect coverage by running `dart test --coverage=.dart_tool/coverage`. |
| 23 | 3. Interpret the results using the provided script or standard tools. |
| 24 | 4. Add tests to cover missed lines. |
| 25 | |
| 26 | ## Running Coverage |
| 27 | Run the following command to collect coverage in JSON format: |
| 28 | ```bash |
| 29 | dart test --coverage=.dart_tool/coverage |
| 30 | ``` |
| 31 | |
| 32 | > [!NOTE] |
| 33 | > We use `.dart_tool/coverage` as the output directory because `.dart_tool` |
| 34 | > is typically already ignored in `.gitignore` files. |
| 35 | |
| 36 | > [!TIP] |
| 37 | > For projects with complex conditional logic, you can pass the |
| 38 | > `--branch-coverage` flag to `dart test` to collect branch-level coverage. |
| 39 | |
| 40 | ## Interpreting Results |
| 41 | |
| 42 | ### Option 1: Use the custom interpreter script |
| 43 | This repository includes a zero-dependency script that parses the raw JSON |
| 44 | output and provides a summary of covered percentage and missed lines. |
| 45 | |
| 46 | Run it from the project root (adjust path to script as needed): |
| 47 | ```bash |
| 48 | dart run skills/dart-test-coverage/scripts/interpret_coverage.dart .dart_tool/coverage <package_name> |
| 49 | ``` |
| 50 | Replace `<package_name>` with the name from `pubspec.yaml`. |
| 51 | |
| 52 | Example Output: |
| 53 | ``` |
| 54 | package:my_pkg/src/file.dart: 50.0% (2/4 lines) |
| 55 | Missed lines: 3, 4 |
| 56 | ``` |
| 57 | |
| 58 | ### Option 2: Use package:coverage |
| 59 | If `package:test` is installed, `package:coverage` is likely available as a |
| 60 | transitive dependency. You can use its `format_coverage` tool. |
| 61 | |
| 62 | To get a human-readable "pretty print" of the coverage: |
| 63 | ```bash |
| 64 | dart run coverage:format_coverage --in=.dart_tool/coverage --out=stdout --pretty-print --report-on=lib |
| 65 | ``` |
| 66 | This will output the file content with hit counts on the left (e.g., `0|` for |
| 67 | missed lines). |
| 68 | |
| 69 | ## Best Practices for Reporting Results |
| 70 | When presenting coverage results to the user, follow these guidelines: |
| 71 | 1. **State the high-level percentage first** to give immediate context. |
| 72 | 2. **Identify specific files and missed lines** clearly. |
| 73 | 3. **Translate line numbers to code**: Don't just say "lines 3-6 are missed". |
| 74 | Look at the source file and tell the user which functions or blocks are |
| 75 | untested (e.g., "The `divide` function is missing coverage"). |
| 76 | 4. **Propose concrete fixes**: Provide example test code that the user can |
| 77 | immediately apply to cover the missed lines. |
| 78 | 5. **Use tables for multi-file summaries**: When reporting on multiple files, |
| 79 | use a markdown table with columns for File, Coverage %, and Missed Lines |
| 80 | to make the summary easy to scan. |
| 81 | |
| 82 | ## Constraints |
| 83 | - ALWAYS verify that tests pass before collecting coverage. |
| 84 | - DO NOT commit the `.dart_tool/coverage` directory. |
| 85 | - Focus coverage improvements on `lib/` files, not `test/` or generated files. |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
