Generated Reports

After tests complete, three files are written to the Reports folder inside bin\Debug\net10.0\ (configurable via ReportsFolderPath).

ComponentSpecifications.yml

A YAML specification document listing all features and scenarios. The ReqNRoll and BDDfy adapters additionally include the BDD steps (Given/When/Then/And/But) for each scenario.

ComponentSpecificationsWithExamples.html

An HTML specification file with embedded sequence diagrams for each test scenario. Features and scenarios are grouped hierarchically.

Behaviour: If any test in the run has failed, this file is written as blank. This prevents publishing stale or misleading specifications when the test suite is not fully passing.

FeaturesReport.html

A full test run report including:

• Execution summary — Total pass/fail/skip counts and run duration
• Sequence diagrams — Embedded for each scenario
• BDD steps — Included when using ReqNRoll or BDDfy
• Failure details — Error messages and stack traces for failed tests

Report Features

Both HTML reports include:

• Search — A search bar that filters features and scenarios by keyword. Supports quoted phrases for exact matching. Supports @tag syntax for Cucumber-style tag expression filtering (e.g. @smoke and @api, not @flaky, (@ui or @api) and not @slow).
• Happy path filter — A toggle to show only scenarios marked as happy path.
• Click-to-reveal PlantUML — Click any diagram image to reveal the raw PlantUML code behind it.
• Feature grouping — Tests are grouped by feature (test class / story title / feature file).
• Context menu — Right-click any diagram (SVG, flame chart, or call tree) for copy/save options including PNG, SVG, and diagram source. See Inline SVG Rendering for details.
• Status filter — Toggle buttons for each ScenarioResult value to show/hide scenarios by status.
• Category filter — When scenarios have categories, filter by category with AND/OR toggle (LightBDD, ReqNRoll).
• Pie chart — A donut chart showing the pass/fail/skip/bypass breakdown with a pass rate percentage in the centre (FeaturesReport only).
• Duration columns — Feature summary table includes Duration, Avg, and Longest columns when scenario durations are available.
• CI metadata — When running in CI (GitHub Actions or Azure DevOps), the report displays build number, branch, commit SHA, and a link to the pipeline run.
• Step numbering — Configurable hierarchical step numbers (e.g. 1., 2., 2.1.) via SpecificationsShowStepNumbers and FeaturesReportShowStepNumbers.
• Custom branding — Inject custom CSS, favicon, and logo HTML via ReportConfigurationOptions.
• DocString rendering — Steps with a DocString property render a <pre> code block below the step text.
• Rules grouping — Scenarios with a Rule property are grouped under a collapsible rule heading.
• Examples / Scenario Outline tables — Scenarios sharing an OutlineId are rendered as examples tables with parameter columns and per-row status icons.

Scenario Result Statuses

Each scenario and step is assigned a ScenarioResult status. The report renders each status with a colour-coded circular icon:

Status	Icon	Colour	Meaning
Passed	✓	Green (#1daf26)	Ran and succeeded
Failed	✗	Red (#cc0000)	Assertion or runtime failure
Skipped	Ø	Grey (#949494)	Deliberately excluded (attribute, filter, inconclusive)
Bypassed	↷	Blue (#2e7bff)	Step body ran, developer opted out; execution continues (LightBDD only)
SkippedAfterFailure	!	Yellow (#fbc800)	Cascading non-execution after a prior step failure

Combined icons: When a parent step has Passed status but contains descendant sub-steps with Bypassed or Skipped status, the parent's icon changes to reflect this:

Descendant statuses	Parent icon	Background	Meaning
Any Bypassed (no Skipped)	✓	Blue (#2e7bff)	Passed overall, but some sub-steps were bypassed
Any Skipped (regardless of Bypassed)	✓	Grey (#949494)	Passed overall, but some sub-steps were skipped

This bubbles up recursively through all ancestor levels. Skipped takes priority over Bypassed because skipping is a bigger deal — it is cascading and prevents execution of subsequent steps, whereas bypassed steps still allow subsequent steps to run. Note that SkippedAfterFailure does not trigger this behaviour (it has its own distinct status).

Framework Status Mappings

Each framework adapter maps its native statuses to TTD's ScenarioResult enum. The table below is organised by TTD status — showing what each status means and exactly which native framework statuses produce it.

Passed — Ran and succeeded

Framework	Native status
xUnit v2	ITestPassed message
xUnit v3	TestResult.Passed
NUnit 4	TestStatus.Passed, TestStatus.Warning
MSTest	UnitTestOutcome.Passed
BDDfy	Result.Passed
ReqNRoll	ScenarioExecutionStatus.OK
LightBDD	ExecutionStatus.Passed

Failed — Assertion or runtime failure

Framework	Native status
xUnit v2	ITestFailed message
xUnit v3	TestResult.Failed
NUnit 4	TestStatus.Failed
MSTest	UnitTestOutcome.Failed, .Error, .Timeout, .Aborted
BDDfy	Result.Failed
ReqNRoll	ScenarioExecutionStatus.TestError, .BindingError
LightBDD	ExecutionStatus.Failed

Skipped — Deliberately excluded; did not execute

Framework	Native status	Condition
xUnit v2	ITestSkipped message	—
xUnit v3	TestResult.Skipped, TestResult.NotRun	—
NUnit 4	TestStatus.Skipped, TestStatus.Inconclusive	—
MSTest	UnitTestOutcome.Inconclusive, .InProgress, .NotRunnable, .Unknown	—
BDDfy	Result.Inconclusive, Result.NotImplemented, Result.NotExecuted	—
ReqNRoll	ScenarioExecutionStatus.UndefinedStep, .StepDefinitionPending, .Skipped	—
LightBDD	ExecutionStatus.Ignored	Scenario-level skip, or step-level with no prior failure
LightBDD	ExecutionStatus.NotRun	Only when the entire scenario was skipped

Bypassed — Step logic intentionally skipped; execution continues (LightBDD only)

Framework	Native status
LightBDD	ExecutionStatus.Bypassed

No other framework produces this status. Bypassed means the step body ran but the developer opted out of its logic (e.g. a precondition was already satisfied). Unlike Skipped, subsequent steps still execute.

SkippedAfterFailure — Cascading non-execution after a prior step failure (LightBDD only)

Framework	Native status	Condition
LightBDD	ExecutionStatus.Ignored	Step-level, when a prior step in the same scenario has already failed
LightBDD	ExecutionStatus.NotRun	When the scenario was not skipped (i.e. a prior failure prevented this step from running)

No other framework produces this status. It distinguishes steps that were never reached due to an earlier failure from steps that were deliberately skipped.

Note on LightBDD context-dependent mapping: LightBDD's Ignored and NotRun statuses map to different TTD statuses depending on two flags: whether a prior step in the scenario has already failed (priorFailure), and whether the entire scenario was skipped at scenario level (scenarioSkipped). This allows the report to distinguish between "deliberately skipped" (grey Ø) and "never reached because something broke" (yellow !).

---

Integration-Specific Report Details

Each integration framework adds its own enhancements to the reports. The sections below describe what each integration contributes beyond the core report structure.

xUnit

The xUnit integration uses the core report generator directly. Features are derived from test class names and scenarios from test display names. Reports are generated when the test run fixture is disposed.

No additional report content is added beyond the core features.

NUnit 4

The NUnit integration uses the core report generator directly. Features are derived from NUnit's TestContext, with scenario names from test method names. Reports are generated in the GlobalTeardown method after all tests complete.

No additional report content is added beyond the core features.

BDDfy (xUnit v3)

The BDDfy integration provides a custom report generator that enhances both HTML reports with:

• BDD steps — Each scenario displays its Given/When/Then steps in a styled list with colour-coded keywords.
• Story descriptions — If a BDDfy story has a description, it is shown below the feature heading in italics.

The YAML specifications also include the BDD steps for each scenario.

Scenario data is collected automatically via BDDfyScenarioCollector during test execution. Reports are typically triggered from an [AssemblyFixture].

ReqNRoll (xUnit v2 & v3)

The ReqNRoll integration provides a custom report generator that enhances both HTML reports with:

• Gherkin steps — Each scenario displays its Given/When/Then steps in a styled list with colour-coded keywords.
• Feature descriptions — If a Gherkin feature file has a description, it is shown below the feature heading in italics.

The YAML specifications also include the Gherkin steps for each scenario.

Additionally, the ReqNRoll integration automatically enhances ReqNRoll's native Cucumber HTML report by injecting sequence diagram image attachments and raw PlantUML code into the Cucumber Messages JSON. This means diagrams appear inside the standard Cucumber report alongside the existing Gherkin steps and results, with no extra configuration needed.

Scenario data is collected via ReqNRollScenarioCollector during test execution. Reports are triggered from a [AfterTestRun] hook.

LightBDD (xUnit 2)

The LightBDD integration takes a different approach — rather than generating its own HTML, it plugs into LightBDD's native report pipeline. Report generation is configured via an extension method on ReportWritersConfiguration:

configuration.CreateStandardReportsWithDiagrams(typeof(MyTest).Assembly, options);

This registers LightBDD's built-in formatters (CustomisableHtmlReportFormatter and YamlReportFormatter) with diagram data injected via the ExampleDiagramsAsCode option. LightBDD handles the HTML rendering, BDD step display, and report lifecycle automatically.

The same three output files are produced, but LightBDD controls the HTML layout and styling natively.

---

CI Summary (Optional)

When WriteCiSummary = true is set on ReportConfigurationOptions, two additional files may be produced:

CiSummary.md

A Markdown summary of the test run, written to the Reports folder and also to the CI platform:

• GitHub Actions — Appended to $GITHUB_STEP_SUMMARY (appears inline in the job summary)
• Azure DevOps — Uploaded via ##vso[task.uploadsummary] (appears in the Extensions tab)

The summary is failure-focused: when tests fail, it shows up to MaxCiSummaryDiagrams failed scenarios with error details and sequence diagram images. When all tests pass, it shows diagrams for the first N scenarios.

CiSummaryInteractive.html

Generated only when WriteCiSummaryInteractiveHtml = true. A self-contained HTML file that renders PlantUML diagrams client-side using the official PlantUML TeaVM JS engine — no server required. Diagrams are lazily rendered via IntersectionObserver as they scroll into view. Can be downloaded as a build artifact and opened in any browser.

---

Browser-Rendered Reports

When using PlantUmlRendering.BrowserJs, the standard HTML reports (FeaturesReport and Specifications) also render PlantUML diagrams client-side in the browser using the same PlantUML TeaVM JS engine. Diagrams are lazily rendered as the user scrolls, keeping initial page load fast even with thousands of diagrams. See PlantUML Browser Rendering for details.

See CI Summary Integration for full configuration and CI platform setup guides.

---

CI Artifact Upload (Optional)

When PublishCiArtifacts = true is set on ReportConfigurationOptions, all report files in the Reports directory (.html, .yml, .md) are published as CI build artifacts:

• Azure DevOps — Each file is uploaded via ##vso[artifact.upload] logging commands during test execution. No additional pipeline configuration needed.
• GitHub Actions — The reports directory path and retention days are written to $GITHUB_OUTPUT. Add a single upload-artifact step to your workflow.

This works alongside the CI summary — the summary appears inline in the build page while the full reports are available as downloadable artifacts.

See CI Artifact Upload for full configuration and workflow examples.