标签：#bdd

If you've ever written test data by hand, you know the ritual: a PersonBuilder , an OrderBuilder , an AddressBuilder … one hand-written builder per class, each one a wall of WithX(...) methods you have to maintain forever. The Test Data Builder and Object Mother patterns are great — the boilerplate is not. XModelBuilder gives you a fluent builder for any C# class out of the box. No per-class builder required. It handles constructor parameters, init-only properties, read-only members, even private backing fields — via reflection, deterministically. Install dotnet add package XModelBuilder 30-second example You can use it fully standalone (no DI container) through a small static facade: using XModelBuilder.Default ; var order = For . Model < Order >() . With ( x => x . OrderDate , new DateTime ( 2026 , 7 , 1 )) . With ( x => x . Lines [ 0 ]. Product , "Widget" ) // deep paths + indexers just work . With ( x => x . Lines [ 0 ]. Quantity , 3 ) . Build (); No OrderBuilder , no OrderLineBuilder . The Lines[0].Product path drills into a nested collection element and sets it for you. Need a whole list? Create.Models<Order>(10) . Deterministic fakers, seeded once Random test data that changes every run is a debugging nightmare. XModelBuilder ships a seeded, dependency-free faker (and a Bogus integration if you prefer). Register it once: services . AddXModelBuilder () . AddXFaker ( seed : 12345 ); // reproducible values, every run Then let it fill in the noise while you set only what your test actually cares about: var order = xprovider . For < Order >() . With ( x => x . Id , p => p . XFake (). NewGuid ()) . With ( x => x . Customer . Name , p => p . Bogus (). Company . CompanyName ()) . With ( x => x . Lines [ 0 ]. Quantity , 3 ) . Build (); XFake().NewGuid("customer-acme") even gives you a stable GUID from a name — same key, same GUID, regardless of call order or parallelism. Deterministic by design. Build a whole list: BuildMany Need ten of something, each slightly differ

Everyone's writing specs for AI now. We hand the model a markdown file, tell it what we want, and hope it builds the right thing. It mostly works — until it doesn't. Markdown has quietly become the spec language. People reach for it as the DSL for their AI-driven workflows — headings, bullet lists, the odd table — and treat that loose structure as if it were a contract. The thing is, it isn't a DSL. It's markdown. It's prose formatting with no grammar to enforce, no structure you can execute, no shared vocabulary, and no way to tell whether the spec and the code still agree. You're leaning on a document format to do a job it was never built for, and you hit the limit the moment you want the spec to actually mean something a machine can check. Before you go down that road, I want to make a small, slightly absurd suggestion. Eat a cucumber. What I actually mean Gherkin is the plain-text language behind Cucumber , a tool that's been around for years in the behavior-driven development (BDD) world. It looks like this: Feature : User login Scenario : Successful login with valid credentials Given a registered user "ada@example.com" When she logs in with the correct password Then she should land on her dashboard And she should see a welcome message Scenario : Rejected login with wrong password Given a registered user "ada@example.com" When she logs in with an incorrect password Then she should see an "invalid credentials" error And she should remain on the login page That's it. Feature , Scenario , Given / When / Then . Structured enough that a machine can parse it, loose enough that a product manager can write it. The gap it bridges Most specs live at one of two extremes. On one end you have written specs : docs, tickets, markdown files. Readable by anyone, but inert. Nothing checks whether they're still true. They rot the moment the code moves on. On the other end you have tests : precise, executable, always honest — but written in code, illegible to half the people who a