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

Data format: The .yml extension is the default for Specifications and TestRunReport data files. Set SpecificationsDataFormat or TestRunReportDataFormat to DataFormat.Json to produce .json files instead.

File names: All file names are configurable via HtmlSpecificationsFileName, HtmlTestRunReportFileName, and YamlSpecificationsFileName on ReportConfigurationOptions.

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.

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.

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, BDDfy, LightBDD, or Step Tracking
• Failure details — Error messages and stack traces for failed tests

A machine-readable structured data file containing the complete test run results, including PlantUML diagram source and HTTP interaction traces for each scenario. This file is designed for automated debugging, CI tooling, and programmatic analysis.

Data format: The default format is JSON (TestRunReportDataFormat = DataFormat.Json). Set to DataFormat.Yaml or DataFormat.Xml to produce .yml or .xml files instead.

The top-level structure contains the test run time window and a list of features with nested scenarios:

{
  "startTime": "2026-01-01T10:00:00Z",
  "endTime": "2026-01-01T10:05:00Z",
  "features": [
    {
      "name": "Order Management",
      "endpoint": "/api/orders",
      "description": "...",
      "labels": ["api"],
      "scenarios": [
        {
          "id": "test-runtime-id",
          "name": "Place order successfully",
          "result": "Passed",
          "durationSeconds": 1.234,
          "isHappyPath": true,
          "errorMessage": null,
          "errorStackTrace": null,
          "labels": ["smoke"],
          "categories": ["Integration"],
          "steps": [
            {
              "keyword": "Given",
              "text": "a valid order request",
              "status": "Passed",
              "durationSeconds": 0.1,
              "subSteps": []
            }
          ],
          "diagrams": [
            "@startuml\nTestClient -> OrderService : POST /api/orders\nOrderService --> TestClient : 201 Created\n@enduml"
          ],
          "httpInteractions": [
            {
              "type": "Request",
              "method": "POST",
              "uri": "https://api.example.com/orders",
              "serviceName": "OrderService",
              "callerName": "TestClient",
              "content": "{\"item\":\"widget\",\"quantity\":1}",
              "headers": [
                { "key": "Content-Type", "value": "application/json" }
              ],
              "statusCode": null,
              "traceId": "guid",
              "requestResponseId": "guid",
              "timestamp": "2026-01-01T10:00:01.000Z"
            },
            {
              "type": "Response",
              "method": "POST",
              "uri": "https://api.example.com/orders",
              "serviceName": "OrderService",
              "callerName": "TestClient",
              "content": "{\"id\":42}",
              "headers": [
                { "key": "Content-Type", "value": "application/json" }
              ],
              "statusCode": "Created",
              "traceId": "guid",
              "requestResponseId": "guid",
              "timestamp": "2026-01-01T10:00:01.050Z"
            }
          ]
        }
      ]
    }
  ]
}

Note: The diagrams and httpInteractions fields are only present when diagram/tracking data is available (i.e. when CreateStandardReportsWithDiagrams is used). When calling GenerateTestRunReportData directly without passing diagrams or logs, these fields are omitted.

A formal schema file is generated alongside the data file to enable validation and IDE auto-complete:

The schema file is always generated in the same Reports folder as the data file. It defines:

• All field names to the matching casing convention (camelCase for JSON/YAML, PascalCase for XML)
• Field types (string, number, boolean, array, object)
• Enum values for result and status fields (Passed, Failed, Skipped, Bypassed, SkippedAfterFailure)
• Recursive step/subStep definitions
• The full HTTP interaction structure including headers

You can also generate a schema file independently:

ReportGenerator.GenerateTestRunReportSchema("TestRunReport.schema.json", DataFormat.Json);
ReportGenerator.GenerateTestRunReportSchema("TestRunReport.schema.xsd", DataFormat.Xml);

Both HTML reports include:

• Search — A powerful search bar with boolean operators (&&, ||, !!), tag filtering (@tag), status filtering ($status), quoted phrases, and parenthesized grouping. See Search Syntax for full documentation.
• 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 ExecutionResult 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 (TestRunReport 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 TestRunReportShowStepNumbers.
• 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. When a DocStringMediaType is specified (e.g. json, xml), it is used for syntax highlighting.
• Rules grouping — Scenarios with a Rule property are grouped under a collapsible rule heading. Background step detection is scoped per-rule when rules are present.
• Examples / Scenario Outline tables — Scenarios sharing an OutlineId are rendered as examples tables with parameter columns and per-row status icons.
• Failure clustering — Failed scenarios are automatically grouped by similar error messages and stack traces. When multiple scenarios fail with the same root cause, the report collapses them under a single cluster heading, making it easier to identify systemic failures.
• Expected/Actual diff rendering — When a failed scenario's error message contains "Expected: X" / "Actual: Y" patterns (common in assertion libraries), the report automatically parses these and renders an inline visual diff highlighting the differences.
• Background steps — When multiple scenarios in a feature (or Rule) share the same leading steps, those steps are automatically detected and rendered in a collapsible "Background" section above the scenario steps. This avoids repetition and mirrors the Gherkin Background keyword. See Step Tracking#Background Steps.
• File attachments — Steps can include FileAttachment entries (name + relative path) that are rendered as downloadable links in the report. Attachments can be added via Track.Attachment() (any framework), LightBDD's step attachment API, or ReqNRoll's IReqnrollOutputHelper.AddAttachment(). See Step Tracking#File Attachments.
• Step comments — Steps with a Comments property render comment text below the step. In LightBDD, comments are added via StepExecution.Current.Comment(). See Tags and Attributes#Step Comments.
• Database toggle — When any diagram in the report contains a database or collections participant (from CosmosDB, EF Core, MongoDB, DynamoDB, Spanner, BigQuery, Redis, distributed caches, or any extension that renders as a database/collections shape), a "Databases Shown" / "Databases Hidden" toggle button appears in the toolbar. Clicking it hides all database and cache participants and their associated arrows, simplifying the diagram to show only service-to-service communication. The toggle works at both report level and scenario level. See Tracking Custom Dependencies for how participants are assigned the database or collections shape.

Each scenario and step is assigned an ExecutionResult 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.

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:

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).

Each framework adapter maps its native statuses to Kronikol's ExecutionResult enum. The tables below show which native statuses from each framework produce each Kronikol status, split by scenario level and step level.

These mappings determine the overall status icon shown next to each scenario in the report. Every framework provides scenario-level statuses.

Note: SkippedAfterFailure does not apply at scenario level — it is a step-level status only. Bypassed is exclusive to LightBDD.

These mappings determine the status icon shown next to each BDD step (Given/When/Then) within a scenario. Only BDDfy, ReqNRoll, and LightBDD capture step-level statuses; the other frameworks have no step concept.

BDDfy footnotes — BDDfy's NotExecuted maps to different statuses depending on whether a prior step failed:

1. NotExecuted → Skipped: When no prior step in the scenario has failed
2. NotExecuted → SkippedAfterFailure: When a prior step in the same scenario has already failed

ReqNRoll footnotes — ReqNRoll's Skipped maps to different statuses depending on whether a prior step failed:

3. Skipped → Skipped: When no prior step in the scenario has failed
4. Skipped → SkippedAfterFailure: When a prior step in the same scenario has already failed

LightBDD footnotes — LightBDD's Ignored and NotRun map to different statuses depending on both scenario-level skip state and prior step failure:

5. Ignored → Skipped: When the entire scenario is skipped, or when no prior step has failed
6. NotRun → Skipped: Only when the entire scenario was skipped at scenario level
7. Ignored → SkippedAfterFailure: When the scenario was not skipped and a prior step has already failed
8. NotRun → SkippedAfterFailure: When the scenario was not skipped (i.e. a prior failure prevented this step from running)

When GroupParameterizedTests is enabled (default: true), parameterized tests that share the same test method are automatically grouped into a single collapsible entry with an interactive parameter table. This reduces report clutter when a single test method is run with many different inputs.

Scenarios are grouped when they share a common OutlineId (set by frameworks like ReqNRoll for Scenario Outlines) or when their display names share the same base name with varying parameter suffixes (e.g. Process(region: UK) and Process(region: US)).

The parameter table uses one of two layouts:

• R1 — Scalar Columns: When the group has a small number of well-defined parameters (≤ MaxParameterColumns), each parameter gets its own column under an "Input Parameters" header. This gives a clean, spreadsheet-like view.
• R0 — Fallback: When there are too many parameters, or parameters cannot be cleanly extracted, each row shows the full test case display name in a single "Test Case" column.

Each row in the parameter table shows the test's status badge and duration. Clicking a row switches the visible:

• Detail panel — Steps, tabular parameters, and failure details for that specific test case
• Sequence diagrams — The diagrams rendered for that specific test case (or a single diagram with an "All diagrams identical" badge when every test case produces the same diagram)
• Activity diagrams and flame charts — Whole-test-flow visualisations, when internal flow tracking is enabled

Additional features on parameterized groups:

• Copy button — Copies the group name to clipboard
• Scenario link — Deep-linkable anchor for the group
• Per-row deep linking — Each row has a data-scenario-id attribute. Navigating to #scenario-test-a-1 will open the group and select the matching row.
• Search highlighting — When using the search bar, matching rows within parameterized groups are highlighted with a blue outline and the first matching row is auto-selected.

When using xUnit v3, the library attempts to extract parameter names and values directly from xUnit's IXunitTestMethod.Parameters and TestMethodArguments APIs. This provides more reliable parameter column headers than display name parsing, especially for complex parameter types. The library falls back to display name parsing when structured extraction is unavailable.

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

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.

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.

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].

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.

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.

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

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.

When using PlantUmlRendering.BrowserJs, the standard HTML reports (TestRunReport 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.

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.

Sequence diagrams in HTML reports are stored as gzip-compressed base64 in data-plantuml-z attributes. The browser-side JavaScript decompresses and renders them dynamically. This means you cannot find diagram content by searching the HTML source with plain text — the content is opaque base64 strings.

To inspect diagram content programmatically:

# PowerShell: Decompress a diagram from the report
$html = Get-Content "Reports/TestRunReport.html" -Raw
$m = [regex]::Match($html, 'data-plantuml-z="([^"]+)"')
$bytes = [Convert]::FromBase64String($m.Groups[1].Value)
$ms = [System.IO.MemoryStream]::new($bytes)
$gz = [System.IO.Compression.GZipStream]::new($ms, 'Decompress')
$sr = [System.IO.StreamReader]::new($gz)
$sr.ReadToEnd()  # → @startuml ... @enduml

Tip: Use the Click-to-reveal PlantUML feature in the HTML report instead — click any diagram image to see the raw PlantUML source directly in the browser.

The ReportGenerator static class provides methods for generating individual report outputs. Most users call CreateStandardReportsWithDiagrams (which calls the others internally), but the individual methods are available for custom pipelines.

Generates all standard reports (HTML specifications, YAML specs, test run report, component diagram) in one call:

public static void CreateStandardReportsWithDiagrams(
    Feature[] features,
    DateTime startRunTime,
    DateTime endRunTime,
    ReportConfigurationOptions options);

Generates a single HTML report file with embedded diagrams. Returns the file path of the generated report. This method accepts all the rendering and styling options as parameters:

public static string GenerateHtmlReport(
    DefaultDiagramsFetcher.DiagramAsCode[] diagrams,
    Feature[] features,
    DateTime startRunTime,
    DateTime endRunTime,
    string? stylesheet,
    string fileName,
    string title,
    bool includeTestRunData,
    bool generateBlankOnFailedTests = false,
    bool lazyLoadImages = true,
    DiagramFormat diagramFormat = DiagramFormat.PlantUml,
    PlantUmlRendering plantUmlRendering = PlantUmlRendering.BrowserJs,
    bool inlineSvgRendering = false,
    bool internalFlowTracking = false,
    string internalFlowDataScript = "",
    Dictionary<string, InternalFlowSegment>? wholeTestSegments = null,
    RequestResponseLog[]? trackedLogs = null,
    WholeTestFlowVisualization wholeTestVisualization = WholeTestFlowVisualization.None,
    CiMetadata? ciMetadata = null,
    bool showStepNumbers = false,
    string? customCss = null,
    string? customFaviconBase64 = null,
    string? customLogoHtml = null,
    bool groupParameterizedTests = true,
    int maxParameterColumns = 10,
    bool titleizeParameterNames = true);

Generates a YAML or JSON specifications file. Returns the file path:

public static string GenerateSpecificationsData(
    Feature[] features,
    string fileName,
    string title,
    DataFormat format,
    bool generateBlankOnFailedTests = false);

Generates a test run report in YAML, JSON, or XML format. Returns the file path:

public static string GenerateTestRunReportData(
    Feature[] features,
    DateTime startTime,
    DateTime endTime,
    string fileName,
    DataFormat format,
    DefaultDiagramsFetcher.DiagramAsCode[]? diagrams = null,
    RequestResponseLog[]? trackedLogs = null);

Generates a JSON or XML schema file for the test run report format. Returns the file path:

public static string GenerateTestRunReportSchema(
    string fileName,
    DataFormat format);

If you are calling RequestResponseLogger.Log() (e.g. from a custom tracker) and the entries don't appear in the generated report:

1. Check TestId matches — Entries are grouped by TestId. If the TestId you pass to RequestResponseLogger.Log() doesn't match what BDDfy/xUnit/ReqNRoll uses for the scenario, the entries will be orphaned.
2. Check TrackingIgnore — Entries with TrackingIgnore = true are excluded from diagram rendering.
3. Pair your Request and Response — Each interaction needs both a Request and Response entry with matching TraceId and RequestResponseId. An unpaired entry produces an incomplete arrow.
4. Check timing — Ensure logging happens before report generation. If you log entries after CreateStandardReportsWithDiagrams() runs, they won't appear.
5. Don't search HTML with plain text — Diagrams are stored as gzip-compressed base64 in data-plantuml-z attributes (see Diagram Storage Format above). Plain text search for participant names or URIs will return zero results.
6. YAML/JSON data files don't contain diagrams — The Specifications.yml and TestRunReport.yml files contain scenario metadata only, not PlantUML diagram content. Diagrams are only in the .html reports.

When upgrading Kronikol versions, changing tracking configuration, or refactoring test fixtures, tracked interactions can silently decrease. Tests continue to pass, but diagrams lose detail. Always validate tracking fidelity after configuration changes.

1. Capture a baseline before any changes — run your full test suite and save the JSON report:

   Copy-Item "Reports/TestRunReport.json" "Reports/TestRunReport.baseline.json"

2. Make changes one at a time for easier diagnosis.

3. Compare key metrics against the baseline:

4. Accept increases when explained by the change (e.g. adding verbosity, adding tracking to new clients).

5. Reject decreases in messaging interactions — these indicate a tracking regression that no test failure will catch.

$gold = Get-Content "TestRunReport.baseline.json" -Raw | ConvertFrom-Json
$current = Get-Content "TestRunReport.json" -Raw | ConvertFrom-Json

$goldCount = ($gold.Features | ForEach-Object { $_.Scenarios } | ForEach-Object { $_.httpInteractions }).Count
$currentCount = ($current.Features | ForEach-Object { $_.Scenarios } | ForEach-Object { $_.httpInteractions }).Count

Write-Host "Baseline: $goldCount interactions, Current: $currentCount interactions"
if ($currentCount -lt $goldCount * 0.99) {
    Write-Warning "Interaction count dropped by more than 1% — investigate before committing"
}