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. See Framework Status Mappings below for full details on what each status renders as, its tooltip text, and which native framework statuses produce it.

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 shows each TTD status, its meaning, and which native statuses from each framework produce it.

TTD Status	Icon	Colour	Description	xUnit v2	xUnit v3	NUnit 4	MSTest	BDDfy	ReqNRoll	LightBDD
Passed	✓	Green (#1daf26)	Ran and all assertions succeeded	ITestPassed	Passed	Passed, Warning	Passed	Passed	OK	Passed
Failed	✗	Red (#cc0000)	Assertion failed or unhandled exception	ITestFailed	Failed	Failed	Failed, Error, Timeout, Aborted	Failed	TestError, BindingError	Failed
Skipped	Ø	Grey (#949494)	Deliberately excluded; did not execute	ITestSkipped	Skipped, NotRun	Skipped, Inconclusive	Inconclusive, InProgress, NotRunnable, Unknown	Inconclusive, NotImplemented, NotExecuted	UndefinedStep, StepDefinitionPending, Skipped	Ignored¹, NotRun²
Bypassed	↷	Blue (#2e7bff)	Step body ran but logic was opted out; subsequent steps still execute	—	—	—	—	—	—	Bypassed
SkippedAfterFailure	!	Yellow (#fbc800)	Never reached because a prior step failed (cascading non-execution)	—	—	—	—	—	—	Ignored³, NotRun⁴

LightBDD footnotes — LightBDD's Ignored and NotRun map to different TTD statuses depending on context:

1. Ignored → Skipped: When the entire scenario is skipped, or when the step is ignored at step-level but no prior step has failed
2. NotRun → Skipped: Only when the entire scenario was skipped at scenario level
3. Ignored → SkippedAfterFailure: When the step is ignored at step-level and a prior step in the same scenario has already failed
4. NotRun → SkippedAfterFailure: When the scenario was not skipped (i.e. a prior failure prevented this step from running)

---

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.