The Kronikol.Extensions.SqlClient package adds SQL Server operation tracking to your test diagrams via Microsoft.Data.SqlClient's built-in DiagnosticSource instrumentation. No production code changes required.

Zero production changes. SqlClient emits diagnostic events automatically. This extension subscribes to them globally, so every SqlConnection in the process is tracked.

Microsoft.Data.SqlClient publishes DiagnosticSource events under "SqlClientDiagnosticListener". The SqlClientDiagnosticTracker subscribes and handles both modern (WriteCommandBefore/WriteCommandAfter) and legacy (ExecuteReader.Start/ExecuteReader.Stop) event naming patterns. Commands are correlated via OperationId GUID, classified by UnifiedSqlClassifier, and logged to RequestResponseLogger.

dotnet add package Kronikol.Extensions.SqlClient

services.AddSqlServerTestTracking(options =>
{
    options.Verbosity = SqlTrackingVerbosityLevel.Detailed;
});

SqlClientTestTracking.EnsureTracking(new SqlClientTrackingOptions
{
    Verbosity = SqlTrackingVerbosityLevel.Detailed
});

// In teardown:
SqlClientTestTracking.Reset();

All options inherit from SqlTrackingOptionsBase.

Response arrows in diagrams now show actual data instead of being empty. The ResponseDetail option controls the level of detail:

Set LogResponseContent = false to restore previous empty-arrow behaviour.

In addition to the zero-change DiagnosticSource approach above, the SqlClient extension also provides a connection-wrapping approach. This is useful when DiagnosticSource instrumentation is unavailable, disabled, or when you need response payload capture from ExecuteReader/ExecuteScalar.

using Microsoft.Data.SqlClient;
using Kronikol.Extensions.SqlClient;

var connection = new SqlConnection(connectionString)
    .WithTestTracking(new SqlClientTrackingOptions
    {
        ServiceName = "SQL Server",
        Verbosity = SqlTrackingVerbosityLevel.Detailed,
        CurrentTestInfoFetcher = CurrentTestInfo.Fetcher
    });

SqlConnection.WithTestTracking() returns a TrackingSqlConnection (which extends DbConnection), so it works transparently with any code that accepts DbConnection — including Dapper, raw ADO.NET, and DI registrations.

builder.ConfigureTestServices(services =>
{
    services.AddScoped<DbConnection>(sp =>
    {
        var inner = new SqlConnection(connectionString);
        return inner.WithTestTracking(new SqlClientTrackingOptions
        {
            ServiceName = "SQL Server",
            Verbosity = SqlTrackingVerbosityLevel.Detailed,
            CurrentTestInfoFetcher = CurrentTestInfo.Fetcher
        });
    });
});

DiagnosticSource vs Wrapping: The DiagnosticSource approach (Option A/B above) requires zero production code changes but cannot capture response payloads. The wrapping approach captures response data from ExecuteReader and ExecuteScalar, but requires the connection to be wrapped. Choose based on your needs — you can use both in the same project for different connections.