Writing executable specifications with Bobcat in C#

Critter Stack's new Bobcat 1.0 turns ordinary C# tests into readable executable specifications. The author starts from an existing xUnit test, adds step helpers, then covers decision tables and set verification for collections. It is a practical walkthrough for .NET teams who want reviewable tests without a Gherkin layer.

Key points

• Adding [BobcatFeature] to an existing xUnit test is enough; xUnit v3, TUnit, NUnit and MSTest (3.10+) are supported
• Step helpers must be internal, not private, because the generated interceptor is an extension method
• SpecAssert.Check records mismatches and lets the scenario continue; the adapter fails the test once at the end
• TableRunner.Run calls a row method per table row, and out parameters act as extra output columns
• Set verification with keyColumns marks rows as EXTRA, MISSING, FAIL or ORDER
• xUnit v2 has no adapter; use the shipped Bobcat.* runner adapter, since hand-rolled ones may never set the verdict

Bobcat 1.0 is out, a tool from the Critter Stack team for writing executable specifications. It descends from Storyteller and, before that, FitNesse, but drops the separate Gherkin files. A specification is a C# test, so developers keep authoring it while domain experts review the rendered steps.

The article walks through one overdraft rule. An existing xUnit test becomes a specification by adding a feature attribute and comments, and helper methods marked with Given, When and Then attributes record each step. Boundary cases move into a pipe or markdown table that a row method runs, and collection checks use set verification with EXTRA, MISSING and ORDER verdicts. Helpers must be internal, and SpecAssert.Check records mismatches instead of stopping the run.

Real-world use

• Testing business rules with many boundary cases, such as account balances, pricing or tax rules, as decision tables
• Sharing rules with product and domain reviewers through rendered steps instead of Gherkin files
• Checking that a transaction history contains exactly the expected rows, with EXTRA and MISSING verdicts

Why it matters

You can turn existing xUnit tests into reviewable specifications with little change to their logic. Table and set verdicts show exactly which row or history entry disagrees, which helps in data-heavy test suites.

Related stories

• Metalama 2027.0 adds interceptors to redirect method calls at build timePMMetalama / PostSharp Blog4 d ago
• Bobcat 1.0 is out: readable C# specifications projected from your testsJMJeremy D. Miller (The Shade Tree Developer)6 d ago
• C# 14 extension members: the shadowing bug the compiler won't warn you aboutDVDEV Community: #csharp1 d ago