JustDummies

Every library refuses something. Most do it by accident and apologise in the issue tracker. JustDummies does it on purpose and writes the boundary down. This page explains where that boundary runs, so you can decide whether it is the right library for you — and so its refusals stop looking like gaps.

“Just dummies” is a scope, not a slogan

The name is the specification. A dummy is a value a test needs and does not care about: it must exist and be well-formed for the code to run, and its value never reaches the assertion and cannot change the outcome. Data that takes part in what the test is trying to verify is not a dummy — whether or not it appears in the assertion itself.

What the library guarantees about such a value is narrow and exact: it is arbitrary, and it is valid for the constraints declared at the call site. It is not a statistically ideal draw, not a universal generator, and not a constraint solver.

Both halves do work. Drop the guarantee and a dummy is unusable, because a value that violates the domain fails for reasons the test never meant to explore. Drop the definition and the scope quietly becomes something else: generate a value the test’s outcome depends on and you have written a property, which this library runs with a sample size of one and cannot defend. The getting-started guide shows exactly where that line runs.

That is narrower than it could be, deliberately. The library’s job is to make a test say what it means and stay reproducible; anything beyond that competes for the same complexity budget and pays for itself in surprises.

Bound the ambition, never the correctness

The rule the whole design follows has two halves, and both matter (ADR-0046 opens in a new tab):

• Bounded ambition. There is a limit to what the generator will attempt.
• Unbounded correctness. There is no limit on what it guarantees once it does attempt. A drawn value satisfies every constraint declared — always, with no “usually” attached.

So when a case falls outside what the library attempts, the answer is a clear refusal naming what cannot be honoured. It is never a value produced by a mechanism nobody can reason about.

The bounds, and why each one is there

None of these is a temporary limitation waiting for someone to find the time. Each is a decision with its reasoning recorded, and each can be revisited — by changing the decision, not by working around it.

A refusal is a feature

The alternative to refusing is guessing, and guessing is expensive in a place that is meant to be boring. A generator that quietly returns something when the specification was impossible has moved the failure from the arrange line, where it is obvious, to the assertion, where it looks like a defect in your code.

So a contradiction is refused at the point it is declared, with a message naming both sides:

// Refused, and the message says which two constraints disagree.
string impossible = Any.String().StartingWith("ORDER-").WithLength(3).Generate();

That message is part of the product. A conflict that said only “no value is possible” would leave you bisecting a chain by hand.

What this means for you day to day

You will occasionally have to do something by hand. A pattern outside the regular subset, an aggregate with fifteen fields, a value whose validity depends on another value drawn earlier. The library gives you IAny<T>, .As(...) and Combine, and expects you to assemble the rest — which keeps the result correct by your rules rather than by a convention it guessed.

You will not have to debug the generator. Every refusal names what it could not honour, every draw satisfies what you declared, and every sequential run replays from the seed it reports. When a test using dummies goes red, the defect is in the code under test.

A missing feature is a decision you can read. If something you expected is not there, the reason is written down in the decision base rather than lost in a commit message — which is also what makes it arguable. Open an issue and cite the ADR.