Bobcat 1.0 is out: readable C# specifications projected from your tests

JasperFx has released Bobcat 1.0, an MIT-licensed tool that projects human-readable specifications from the test frameworks you already use, including xUnit.net, TUnit, MSTest and NUnit. No Gherkin or wiki files are needed, only C# or F#. It also brings Supervisor for more reliable integration suites and telemetry output aimed at AI agents debugging failing tests.

Key points

• Bobcat 1.0 projects specifications from xUnit.net, TUnit, MSTest and NUnit tests; no Gherkin or wiki files are needed.
• Markdown-style tables inside table-driven tests are syntax-checked at compile time by source generators.
• The Supervisor library targets flaky, slow infrastructure-heavy integration suites.
• The Wolverine integration package logs retries, dead letter queues, scheduled messages and exceptions to console output.
• Updated JasperFx AI Skills cover troubleshooting specs, watch mode and Supervisor-based CI builds.

JasperFx has shipped Bobcat 1.0, an MIT-licensed tool focused on projecting readable specifications from existing test frameworks rather than mapping external text formats onto code. Tests remain plain C# or F#, with xUnit.net, TUnit, MSTest and NUnit supported. Table-driven tests can use markdown-style tables inside the code, and source generators check that syntax at compile time. A Supervisor library targets flaky, slow infrastructure-heavy integration suites.

The Wolverine integration package records messaging activity such as retries, dead letter queues, scheduled and outgoing messages, and exceptions, and writes it to console output in a format meant for AI agents to read when a test fails. Updated JasperFx AI Skills cover troubleshooting specifications, a watch mode for quicker feedback, and Supervisor-based CI runs. The project also draws on the author's earlier Storyteller work, aiming to keep what worked for data-heavy tests while dropping what made it hard to use.

Real-world use

• Writing data-heavy business rules as C# tests that domain experts can review as readable specifications.
• Debugging failing Wolverine message handler tests with telemetry that an AI agent can act on directly.
• Stabilizing CI runs for integration suites that depend on databases and message brokers.

Why it matters

You can keep specifications in the test projects you already maintain and still produce output that non-developers can review. Integration test stability and failure debugging time are the practical gains to evaluate.

Related stories

• Metalama 2027.0 adds interceptors to redirect method calls at build timePMMetalama / PostSharp Blog4 d ago
• Writing executable specifications with Bobcat in C#JMJeremy D. Miller (The Shade Tree Developer)5 d ago
• C# 14 extension members: the shadowing bug the compiler won't warn you aboutDVDEV Community: #csharp1 d ago