Test coverage
Measured on 2026-09-25 at commit 374e6469e43c, by the release that published this site.
The whole test suite covers 96.8% of the workspace's 34,931 statements. The unit layer alone reaches 85.3%, and the integration layer's instrumented binary 95.0%; the two overlap, so the total is every profile merged rather than either of them added up.
Every number on this page comes from a coverage profile. Module tests produce the unit profiles. Integration coverage comes from two sources: real CLI processes running against disposable repositories, and public API scenarios that combine parsing, configuration, scanning, and rewriting. The measured production scope includes the CLI and all six current public Go modules. The current CCME module has its own public API driver because the CLI still uses the previous major version internally.
The report keeps unit, integration, and combined coverage separate. Combined coverage counts each statement once and marks it covered when either layer reaches it. It supplies the README badge. The integration gate uses only the integration profiles; unit tests cannot satisfy it. A stable release of the measured modules requires both integration and combined coverage to reach 95%. A release candidate publishes its figures without that minimum.
Before calculating a total, the report checks that every expected module and production block is present and that profile provenance matches the run. Missing profiles, mixed revisions, and omitted subpackages fail the report rather than reducing its denominator. The badge and this page are therefore the same number, taken from the same run: the one that gated the release which published this site.
The container cache may reuse a profile when the complete test input layer is byte-for-byte identical: the module, its workspace providers, test-report tool and declared fixtures all participate in that key. A following layer stamps the current source commit only after that identity check. The stamp therefore says the measurement applies to this commit; it does not claim the test process ran again merely because documentation changed. A changed test input misses the cached layer and runs the suite before it can receive a fresh stamp.
By module
| Module / package | Statements | Covered | Coverage |
|---|---|---|---|
pkg/ccme | 1,338 | 1,330 | 99.4% |
pkg/config | 1,198 | 1,168 | 97.5% |
| the module itself | 1,096 | 1,075 | 98.1% |
watch | 102 | 93 | 91.2% |
pkg/manifest | 202 | 200 | 99.0% |
pkg/models | 468 | 467 | 99.8% |
pkg/scanner | 1,474 | 1,445 | 98.0% |
pkg/writer | 3,554 | 3,462 | 97.4% |
services/dispat | 25,132 | 24,266 | 96.6% |
| the module itself | 1 | 1 | 100.0% |
internal/app | 6,515 | 6,312 | 96.9% |
internal/changelog | 442 | 429 | 97.1% |
internal/cli | 1,434 | 1,416 | 98.7% |
internal/cond | 52 | 51 | 98.1% |
internal/config | 3,203 | 3,134 | 97.8% |
internal/envname | 7 | 7 | 100.0% |
internal/execution | 3,580 | 3,360 | 93.9% |
internal/filter | 207 | 206 | 99.5% |
internal/fsx | 39 | 29 | 74.4% |
internal/github | 201 | 196 | 97.5% |
internal/gitx | 2,145 | 2,064 | 96.2% |
internal/globx | 42 | 41 | 97.6% |
internal/graph | 112 | 110 | 98.2% |
internal/httpx | 83 | 63 | 75.9% |
internal/ignore | 64 | 64 | 100.0% |
internal/install | 228 | 224 | 98.2% |
internal/model | 70 | 70 | 100.0% |
internal/plan | 4,134 | 4,017 | 97.2% |
internal/release | 1,403 | 1,358 | 96.8% |
internal/script | 52 | 51 | 98.1% |
internal/selfupdate | 648 | 614 | 94.8% |
internal/webhook | 197 | 188 | 95.4% |
internal/workspaceenv | 273 | 261 | 95.6% |
tools | 1,565 | 1,486 | 95.0% |
namingcheck | 166 | 141 | 84.9% |
testreport | 1,399 | 1,345 | 96.1% |
Coverage measures executed statements, not whether every requirement is correct. The requirement matrix also tracks release-safety cases such as lock failure, interrupted publication, configuration inheritance, and consumer recovery. An uncovered statement may represent a missing workflow or an error path; inspect the profile before deciding whether a new test is useful. A high combined percentage does not prove the integration gate passed. The per-package test inventory (what each package's suite actually asserts) is in Architecture / Testing, and what the suite did rather than what it reached is in test results.
Reproducing
The whole measurement is three commands from the monorepo root, and they are the ones the release workflow runs:
dispat run tests --since all # every module's profile and go test -json log, into coverage/
dispat exec coverage-badge # merges the profiles; writes the badge JSON and the summary table
dispat exec test-report # writes packages/docs/data/report.json, read by this page
Every one of them is a build of Dockerfile.gotest, so none needs a Go toolchain on the machine running it.
--since all is not optional. A run selected by a --since window tests part of the monorepo, so a total from it
would be a number about whichever packages happened to change. That is why the badge is computed by the release
workflow rather than by the per-commit test workflow.
Rebuilding this site with packages/docs/data/report.json in place is what puts the figures back on the page; without
one, the prose stays and the tables are left out.
What each layer contributes
Module tests exercise focused behavior, using both real resources and test doubles where appropriate. The CLI integration suite drives the compiled binary and checks Git state, log events, execution order, signals, and recovery. Its public API scenarios scan manifests, rewrite them, and rescan the result, including failures that must preserve the original files.
DISPAT_COVERDIR enables CLI coverage collection, while the test runner collects public API coverage. Without these
settings, ordinary local tests run without coverage instrumentation. The release gate collects both sources into one
integration profile and compares its production statement inventory with the unit profiles.
The suite's own status and per-area summary are in test results, with the claim-by-claim matrix
in the test plan.