Succeeding with test automation using Bobcat

The Critter Stack team has described the test automation strategy behind Bobcat, its new spec-driven integration testing framework for .NET. The post, written by Jeremy Miller, lays out practices for tests that ship confidence, are cheap to write, run fast, stay reliable and explain their failures. It is a useful reference for .NET teams who want their CI results to be trusted as a merge gate.

Key points

• Bobcat renders existing xUnit, TUnit, NUnit or MSTest tests as readable Given/When/Then specifications.
• Tests name only the data they care about; a declared fill policy supplies defaults for everything else.
• bobcat run --failed reruns only the specifications that failed last time.
• Retries are opt-in: a test needs a Retry trait and a budget, and passes on retry are reported as PassOnRetry.
• Wait for asynchronous work through WolverineFx.Bobcat steps or SpecAssert.EventuallyAsync instead of Thread.Sleep.
• Failing specs report every wrong expectation at once, including row-level diffs for collections.

Bobcat is a new member of the Critter Stack: a spec-driven integration testing framework for .NET. It reuses the xUnit, TUnit, NUnit or MSTest tests developers already write and renders them as readable Given/When/Then specifications with a verdict per step. A supervisor can spread large suites across worker processes. The team says Bobcat already runs Wolverine's CI and gates local changes, which made builds faster and more trustworthy. The library is MIT licensed and works with any .NET application.

The post sets out fifteen recommendations grouped under five goals: confidence to ship, tests that are easy to write, fast feedback, reliability and failures that explain themselves. Useful ideas include setting only the data a test is about, keeping steps declarative, waiting for asynchronous work instead of sleeping, and collecting every disagreement when a test fails. Retries are opt-in and reported separately from clean passes. The original article goes into the commands, helpers and examples in detail.

Real-world use

• Testing business rules such as an overdraft limit in an event-sourced banking API using readable specifications.
• Integration testing message flows and async projections in a Wolverine-based background service with proper waits.
• Splitting a large CI suite across worker processes with isolated databases and rerunning only failed tests.

Why it matters

A green build only means something when tests are fast, stable and explain their failures. The post gives .NET teams a concrete checklist for writing tests and building a trustworthy CI gate.

Related stories

• .NET 8 and 9 End of Support: A Deployment-First Migration ChecklistDVDEV Community: #dotnet2 d ago
• 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