Skip to content

Framework Integration Guides

aryehcitron@gmail.com edited this page May 17, 2026 · 13 revisions

Each framework has a complete, step-by-step integration guide. The sections below summarise the key concepts for each; follow the links for the full walkthrough.

xUnit v3

Full guide: Integration xUnit3

The simplest integration path. Uses xUnit v3 collection fixtures to manage the test lifecycle.

Key components:

  • DiagrammedTestRun — Base class for collection fixture; tracks StartRunTime/EndRunTime and holds a ConcurrentQueue<ITestContext>
  • DiagrammedComponentTest — Base class for test classes; automatically enqueues TestContext.Current on dispose
  • XUnitReportGenerator.CreateStandardReportsWithDiagrams() — Generates all three report files
  • [HappyPath] and [Endpoint("/path")] attributes for test metadata

xUnit v2

Full guide: Integration xUnit2

Same pattern as xUnit v3 but adapted for xUnit v2, which lacks TestContext.Current. Uses AsyncLocal<T> and a custom XunitTestFramework for test identity tracking and report generation.

Key components:

  • ReportingTestFramework — Custom XunitTestFramework that generates reports after all tests complete and captures test results via a message sink wrapper
  • DiagrammedTestRun — Base class for collection fixture; tracks timing and configures ReportLifecycle.Options
  • DiagrammedComponentTest — Base class for test classes; applies [TestTracking] (a BeforeAfterTestAttribute that sets AsyncLocal identity)
  • XUnit2ReportGenerator.CreateStandardReportsWithDiagrams() — Generates all three report files
  • [HappyPath] and [Endpoint("/path")] attributes (using ITraitAttribute + ITraitDiscoverer)

NUnit

Full guide: Integration NUnit

Uses NUnit 4's [SetUpFixture] for test lifecycle management.

Key components:

  • DiagrammedTestRun — Base class for [SetUpFixture] (must be outside any namespace for global fixture)
  • DiagrammedComponentTest — Base class for test fixtures; captures TestContext.CurrentContext in [TearDown]
  • NUnitReportGenerator.CreateStandardReportsWithDiagrams() — Generates all three report files
  • [HappyPath] and [Endpoint("/path")] attributes (NUnit PropertyAttribute based)

Important: Use [FixtureLifeCycle(LifeCycle.InstancePerTestCase)] to ensure each test gets a fresh instance.


MSTest

Full guide: Integration MSTest

Uses MSTest v3's [AssemblyInitialize]/[AssemblyCleanup] for test lifecycle management.

Key components:

  • DiagrammedTestRun — Base class for [TestClass] with [AssemblyInitialize]/[AssemblyCleanup]
  • DiagrammedComponentTest — Base class for test classes; uses AsyncLocal<TestContext> for test identity and enqueues MSTestScenarioInfo on [TestCleanup]
  • MSTestReportGenerator.CreateStandardReportsWithDiagrams() — Generates all three report files
  • [HappyPath] and [Endpoint("/path")] attributes

Note: MSTest's TestContext is instance-based (not static like NUnit/xUnit v3), so the library uses AsyncLocal internally to make it available to the HTTP tracking pipeline.


TUnit

Full guide: Integration TUnit

Uses TUnit's [Before(Test)]/[After(Test)] hooks and TestContext.Current for test lifecycle management. TUnit uses Microsoft.Testing.Platform (not Microsoft.NET.Test.Sdk).

Key components:

  • DiagrammedTestRun — Base class for assembly-level hooks; tracks StartRunTime/EndRunTime and holds a ConcurrentQueue<TestContext>
  • DiagrammedComponentTest — Base class for test classes; uses [After(Test)] to enqueue TestContext for report collection
  • TUnitReportGenerator.CreateStandardReportsWithDiagrams() — Generates all three report files
  • [HappyPath] and [Endpoint("/path")] attributes (TUnit CategoryAttribute and PropertyAttribute based)

Note: TUnit test projects require <OutputType>Exe</OutputType> in the csproj — this is handled automatically by the TUnit meta package.


BDDfy + xUnit v3

Full guide: Integration BDDfy xUnit3

BDD with BDDfy's fluent API (this.Given(...).When(...).Then(...).BDDfy()). Diagrams are injected into both the BDDfy native HTML report and the Kronikol reports.

Key components:

  • BDDfyDiagramsConfigurator.Configure() — Must be called before tests run; registers BDDfy processors
  • BDDfyScenarioCollector — Thread-safe collector for scenario metadata
  • BDDfyReportGenerator.CreateStandardReportsWithDiagrams() — Generates reports with BDD step details
  • Tags: "happy-path", "endpoint:/path" passed via .WithTags()

Note: For xUnit v3, set <OutputType>Exe</OutputType> in the test project's csproj.


LightBDD + xUnit v2

Full guide: Integration LightBDD xUnit2

BDD with LightBDD's C# scenario runner (Runner.RunScenarioAsync(given => ..., when => ..., then => ...)). Uses xUnit v2.

Key components:

  • ReportWritersConfiguration.CreateStandardReportsWithDiagrams() — Fluent extension for LightBDD's report writer pipeline
  • LightBddTestTrackingMessageHandlerOptions — Auto-fetches test info from ScenarioExecutionContext
  • LightBddDiagramsFetcher — Wraps diagrams with LightBDD's DiagramAsCode type

Note: Requires [assembly: ClassCollectionBehavior(AllowTestParallelization = false)].


LightBDD + xUnit v3

Full guide: Integration LightBDD xUnit3

BDD with LightBDD's C# scenario runner (Runner.RunScenarioAsync(given => ..., when => ..., then => ...)). Uses xUnit v3.

Key components:

  • LightBddConfiguration.CreateStandardReportsWithDiagrams() — Extension on LightBddConfiguration that hooks into the report pipeline and registers automatic raw argument capture for rich sub-table rendering of complex objects.
  • ReportWritersConfiguration.CreateStandardReportsWithDiagrams() — Legacy overload; hooks into the report pipeline only (no automatic argument capture).
  • LightBddTestTrackingMessageHandlerOptions — Auto-fetches test info from ScenarioExecutionContext
  • LightBddDiagramsFetcher — Wraps diagrams with LightBDD's DiagramAsCode type

Note: Uses [assembly: TestPipelineStartup(typeof(ConfiguredLightBddScope))] instead of the xUnit v2 scope attribute. Requires <OutputType>Exe</OutputType> in the test project's csproj.

Note: Requires [assembly: ClassCollectionBehavior(AllowTestParallelization = false)].


LightBDD + TUnit

Full guide: Integration LightBDD TUnit

BDD with LightBDD's C# scenario runner (Runner.RunScenarioAsync(given => ..., when => ..., then => ...)). Uses TUnit as the test runner.

Key components:

  • ReportWritersConfiguration.CreateStandardReportsWithDiagrams() — Fluent extension for LightBDD's report writer pipeline
  • LightBddTestTrackingMessageHandlerOptions — Auto-fetches test info from ScenarioExecutionContext
  • LightBddDiagramsFetcher — Wraps diagrams with LightBDD's DiagramAsCode type

Note: Uses [assembly: ConfiguredLightBddScope] with a custom LightBddScopeAttribute subclass. Requires <OutputType>Exe</OutputType> in the test project's csproj.


ReqNRoll + xUnit v2

Full guide: Integration ReqNRoll xUnit2

Gherkin-based BDD with .feature files and [Binding] step definitions.

Key components:

  • ReqNRollTrackingHooks — Auto-registered via reqnroll.json binding assembly; captures scenario IDs, steps, and results
  • ReqNRollReportGenerator.CreateStandardReportsWithDiagrams() — Generates reports with Gherkin step details
  • ReqNRollReportEnhancer — Additionally enhances ReqNRoll's native HTML report with sequence diagram attachments (when the html formatter is enabled in reqnroll.json). The standard custom reports are still generated as before
  • Tags: @happy-path, @endpoint:/path in feature files

Critical: Add to reqnroll.json:

{
  "bindingAssemblies": [
    { "assembly": "Kronikol.ReqNRoll.xUnit2" }
  ],
  "formatters": {
    "html": { "outputFilePath": "reqnroll_report.html" }
  }
}

ReqNRoll + xUnit v3

Full guide: Integration ReqNRoll xUnit3

Identical to the xUnit v2 variant, but targets the xUnit v3 out-of-process runner.

Key differences from xUnit v2:

  • References Kronikol.ReqNRoll.xUnit3 instead of xUnit2
  • Requires <OutputType>Exe</OutputType> in the test project's csproj
  • reqnroll.json references Kronikol.ReqNRoll.xUnit3

ReqNRoll HTML report: Both ReqNRoll packages additionally enhance ReqNRoll's native HTML report with sequence diagrams when the html formatter is enabled in reqnroll.json. This is in addition to the standard custom reports that are always generated in the Reports directory. See the Integration ReqNRoll xUnit2 guide for details.


ReqNRoll + TUnit

Full guide: Integration ReqNRoll TUnit

Identical to the xUnit v3 variant, but uses TUnit as the test runner via the Reqnroll.TUnit package.

Key differences from xUnit v3:

  • References Kronikol.ReqNRoll.TUnit instead of xUnit3
  • Uses Reqnroll.TUnit instead of Reqnroll.xunit.v3
  • Requires <OutputType>Exe</OutputType> and <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> in the csproj
  • Must set <RootNamespace> to avoid namespace collision with TUnit.Core (see guide for details)
  • reqnroll.json references Kronikol.ReqNRoll.TUnit

ReqNRoll HTML report: The ReqNRoll TUnit package additionally enhances ReqNRoll's native HTML report with sequence diagrams when the html formatter is enabled in reqnroll.json. This is in addition to the standard custom reports that are always generated in the Reports directory. See the Integration ReqNRoll xUnit2 guide for details.


Extensions

CosmosDB Extension

Full guide: Integration CosmosDB Extension

The Kronikol.Extensions.CosmosDB package adds Cosmos DB SDK operation tracking. Instead of raw HTTP methods and _rid-encoded URLs, your diagrams show classified operations like Create Document [orders], Query [orders]: SELECT * FROM c WHERE ..., etc.

Key components:

  • CosmosTrackingMessageHandlerDelegatingHandler that classifies Cosmos SDK HTTP traffic and logs to RequestResponseLogger
  • CosmosTrackingMessageHandlerOptions — Service names, verbosity level (Raw/Detailed/Summarised), test info fetcher
  • CosmosClientOptionsExtensions.WithTestTracking() — Extension method on CosmosClientOptions for easy wiring

Works with any test framework and integrates with CosmosDB.InMemoryEmulator via WithHttpMessageHandlerWrapper.


EF Core Relational Extension

Full guide: Integration EF Core Relational Extension

The Kronikol.Extensions.EfCore.Relational package adds EF Core SQL operation tracking. Instead of seeing nothing (EF Core bypasses HttpMessageHandler entirely), your diagrams show classified operations like Select: /ordersdb/Users, Insert: /ordersdb/Orders, StoredProc: /ordersdb/GetReport, etc.

Key components:

  • SqlTrackingInterceptorDbCommandInterceptor that classifies SQL commands and logs to RequestResponseLogger
  • SqlTrackingInterceptorOptions — Service names, verbosity level (Raw/Detailed/Summarised), test info fetcher
  • DbContextOptionsBuilderExtensions.WithSqlTestTracking() — Extension method on DbContextOptionsBuilder for easy wiring
  • SqlOperationClassifier — Static classifier that handles all SQL dialects (SQL Server, PostgreSQL, MySQL, SQLite, Oracle, Spanner)

Works with any test framework and any EF Core relational provider.


Redis Extension

Full guide: Integration Redis Extension

The Kronikol.Extensions.Redis package adds StackExchange.Redis operation tracking with cache hit/miss visualization. Instead of invisible Redis operations, your diagrams show classified operations like Get (Hit): redis://db0/user:123, Set: redis://db0/session:abc, HashGet (Miss): redis://db0/cart:456, etc.

Key components:

  • RedisTrackingDatabaseDispatchProxy-based IDatabase decorator that intercepts Redis operations and logs to RequestResponseLogger
  • RedisTrackingDatabaseOptions — Service names, verbosity level (Raw/Detailed/Summarised), test info fetcher
  • DatabaseExtensions.WithRedisTestTracking() — Extension method on IDatabase for easy wiring
  • DatabaseExtensions.GetTrackedDatabase() — Extension method on IConnectionMultiplexer for easy wiring
  • RedisOperationClassifier — Static classifier with cache hit/miss detection for read operations

Works with any test framework. Uses DispatchProxy because StackExchange.Redis has no built-in interception infrastructure.

Home


Demo


Getting Started

Common Tasks

Integration Guides

Extensions

Configuration

Features

Reference

Clone this wiki locally