Reporters

After every test run, ReqCover hands the finished RequirementsCoverageTracker to every registered RequirementsCoverageReporter. Both built-in reporters write to build/reports/tests/reqcover/ in the project’s working directory.

The SPI

interface RequirementsCoverageReporter {
    fun report(tracker: RequirementsCoverageTracker)
}

Register an implementation via META-INF/services/dev.reqcover.engine.spi.RequirementsCoverageReporter. If no reporter is on the classpath, ReqCover prints a warning to stderr and skips reporting - coverage is still tracked and enforced, you just don’t get a file.

reqcover-reporter-html

Writes build/reports/tests/reqcover/requirements-coverage.html - a plain XHTML table with one row per expected requirement (marked Covered or Not Covered) plus one row per unexpected requirement (a test referenced an ID your source doesn’t define).

reqcover-reporter-xml

Writes build/reports/tests/reqcover/requirements-coverage.xml:

<requirements-coverage total="2" covered="2" coverage="100.0">
  <expected>
    <requirement id="#getVersion" covered="true"/>
    <requirement id="#getHealth/200" covered="true"/>
  </expected>
  <unexpected/>
</requirements-coverage>

total, covered, and coverage are computed the same way as the console summary, so this file is a natural fit for a CI dashboard or a badge generator that wants a machine-readable number rather than the HTML table.

Writing your own reporter

Anything that wants a different format - Markdown for a PR comment, JSON for a dashboard, a call to an external tracking system - is a small RequirementsCoverageReporter implementation away. The tracker gives you expectedRequirements(), verifiedRequirements(), coveredRequirements(), unverifiedRequirements(), and unexpectedRequirements() - see Core Concepts for what each set means.