JustDummiesJust dummies — but seriously powerful ones.
JustDummies generates the arbitrary values a test needs, and lets you state the rules those values have to satisfy.
Not every value in a test carries the scenario. The ones that do not still have to respect the rules of the domain — that is the part JustDummies takes care of. See the full example, step by step.
These four are usually listed as rivals. They answer four different questions, and most projects ask more than one of them. Find the sentence you would say out loud.
I do not care what this value is, but it has to be valid.
Arbitrary values for everything a test does not check, with the rules they must satisfy written where the value is asked for.
In practice: a reference that always starts with ORD-, is uppercase alphanumeric after that prefix, and is between eight and twenty characters long, drawn fresh on every run.
View the repository opens in a new tabI need data that looks real.
A simple fake data generator for C#, F#, and VB.NET — ported from the well-known faker.js.
In practice: names, addresses, emails, phone numbers, product labels — locale-aware, and convincing to a person reading a screenshot or a demo database.
View the repository opens in a new tabJust build me the object. I do not care what is in it.
A library that removes the need to hand-code anonymous variables when setting up a test's fixture.
In practice: one call returns a fully populated object, everything it holds filled in too, including types you did not write — with nothing declared anywhere.
View the repository opens in a new tabThis exact value is what the test checks.
No library at all: the value typed straight into the test, on the line that uses it.
In practice: the amount an assertion compares against, or the status a behaviour turns on. A reader sees it without leaving the test.
Ten criteria, each one a question about your own tests, answered for all four options.
Every answer at a glance, without the notes behind them. Each criterion links down to the block that explains it.
| Criterion | JustDummies | Bogus | AutoFixture | Hardcoded value |
|---|---|---|---|---|
| Will the value get through my own code? | ||||
| Values your own code will accept | ||||
| Rules stated where the value is asked for | ||||
| Filling nested objects for you | ||||
| Will my test still be readable? | ||||
| Showing which value the test checks | ||||
| Describing a valid object once | ||||
| What kind of value do I actually need? | ||||
| Data that looks real | ||||
| Hunting for the value that breaks your code | ||||
| What happens when it goes wrong, and who writes the setup? | ||||
| Replaying the run that failed | ||||
| Caught before the test runs | ||||
| A tool writing the setup for you | ||||
The criteria are grouped by the questions you might ask in your own tests, not by what JustDummies is good at. And JustDummies deliberately does not try to cover every need: its goal is to do one thing well, generating the arbitrary and constrained values your tests need.
Will the generated value get past my own constructor?
Most domain types refuse bad input. OrderReference.Create rejects a string that does not start with ORD-, one shorter than eight characters or longer than twenty, and one carrying anything but an uppercase letter or a digit after the prefix. A test that needs any reference still needs one that clears every check.
Technical term: business invariant, or precondition in design by contract
string reference = Any.String()
.AlphaNumeric()
.InUpperCase()
.StartingWith("ORD-")
.WithLengthBetween(8, 20)
.Generate();A Faker<T> satisfies a domain rule once a RuleFor is written to match it — or a CustomInstantiator that calls the type's own factory. StrictMode(true) then checks that every property has a rule at all. What no check covers is whether a rule produces a value the domain would accept.
A rule a type carries as an annotation — [Range], [StringLength], [RegularExpression] — is already honoured, with no configuration at all. A rule enforced inside a constructor is the other case: generation throws until a Register, a Customize<T> or an ISpecimenBuilder is written to satisfy it.
Valid because a person chose a value they knew was valid. Nothing checks that it still is the day the rule changes.
Can I write "any number between 1 and 100" on the line that needs it?
Some rules belong to one test rather than to the domain: this quantity has to be at least two, this date has to be in the past. The question is whether you can say so on the spot, or have to declare a type, register a customisation or build a fixture first.
Technical term: call site — the place in your code where the value is asked for
int quantity = Any.Int32().Between(1, 100).Generate();A Faker<T> can be built inline in the test, right before Generate, with its rules on it — Random.Int(min, max) and the like. You write those rules out again in every test that needs them.
A rule that lives on the type is honoured everywhere without a line in the test. A rule that belongs to this one test is written inline through Build<T>().With(x => x.Prop, value) — a pinned value, or a lambda you write, one property at a time.
The rule is never stated. You pick a value that happens to satisfy it, and the rule stays in the head of whoever picked it.
My type is three levels deep and the test cares about none of it — who fills it?
An order holds a customer, which holds an address. Either something inspects your class and populates every level, or you supply one generator per type and plug them together.
Technical term: object graph
You supply one generator per type and compose them. Nothing inspects your class and fills the levels underneath.
A nested object is built by hand inside the rule that produces it. Bogus does not descend into it for you.
Every nested object is constructed by hand, level by level, and each constructor is a line you write and then maintain.
Can a reader tell which values the assertion depends on?
A test that builds an order from four arguments does not say which of the four it is about. Drawing three of them and writing the fourth as a literal answers that in the arrangement itself.
RuleFor(x => x.Prop, expected) pins the exact value the assertion checks, so the subject of the test is written down. The rules around it are written down just as visibly.
This is the goal AutoFixture states for itself: the values a test does not care about disappear, because you never describe them. What disappears with them is any statement of what those values must satisfy.
It shows the value the test is about with no indirection at all. Used for the parameters around it as well, the arrangement grows a line per parameter and the subject stops standing out.
The day my type gains a constructor parameter, how many test files do I reopen?
Whatever describes a valid order — a chain of constraints, a set of rules, a builder — is worth writing once and calling from everywhere. The question is what that costs to set up, and how much of it the tool writes for you.
Write the generator once, in your own test project, and every test can call it. The dum tool — the library's own companion CLI — can write that file for you. Neither happens from a single call.
A Faker<T> is defined once and reused across tests, the same way a JustDummies generator is.
An ICustomization packages a set of rules once, in a class of its own, and every test that opts into it gets them.
A literal can move into a named constant or a helper and be shared. You then maintain it by hand, and every test that shares it runs on the same value.
Will a person look at this value, or only an assertion?
Valid and believable are two different jobs. A reference that clears every rule can still read as machine noise. That is fine in an assertion and wrong in a screenshot.
Technical term: fake data — the faker family of libraries
Valid, not believable. There is no catalogue of names, addresses or emails here.
The values are anonymous by design — a string comes out as a property name and a GUID. Looking real is not what AutoFixture is trying to do.
As realistic as the value you type: marie.durand@acme.fr is every bit as convincing as a generated one. You type it again in the next test.
Do I want one arbitrary value, or hundreds looking for a counter-example?
One drawn value per run tells you the code held for that value. The opposite approach runs the same assertion over hundreds of generated inputs, then narrows any failure down to the smallest input that still fails.
Technical term: property-based testing, and shrinking
One value is drawn per run, and you can draw it again. There is no systematic search for the input that fails.
Bogus fills values. It does not run your test repeatedly looking for one that fails.
One anonymous value per request, not a search for the one that makes your code fail.
One value, chosen once, and the same one for the life of the test.
None of the four does this. In .NET the usual answers are FsCheck and CsCheck, and they sit beside any of these rather than replacing one.
CI went red on a drawn value. Can I get that exact value back?
Values that change on every run mean a test can fail today and pass tomorrow. What makes that workable is a number the failing run reports, which draws the same values again when you paste it back.
Technical term: seed
A failing test case reports its seed, and that seed redraws exactly the same values. Each case seeds itself, so a suite running in parallel still hands back the seed of the one that failed. This comes from the xUnit adapter; there is no NUnit or MSTest adapter today.
UseSeed on a Faker, or Randomizer.Seed for the whole run, makes a run repeatable.
There is no seed to set, so a run cannot be replayed value for value. That is a gap rather than a decision: repeatable random numbers are an open request on the project, filed in September 2023.
The same value on every run, because it is the value you typed. Nothing to replay, and nothing that varies.
Do I learn the setup is wrong in the editor, or ten minutes later?
A chain of constraints can contradict itself: at most three characters, and starting with ORD-. Nothing satisfies that. The question is whether it shows up as a build error or as an exception on the first run.
Technical term: Roslyn analyzer
The analyzers ship inside the main package at no extra cost — installing the library installs them, with no paid tier standing between you and them. They catch a self-contradictory constraint immediately, in the editor: at most three characters, say, and starting with ORD-. What stays out of reach here is a domain invariant nobody declared as a rule at all — enforced in ordinary constructor code, with no structured list of a type's own invariants for an analyzer to check completeness against. That is narrower than it sounds: Bogus Premium's analyzer can flag a property with no RuleFor, because a Faker<T>'s properties are a known, enumerable set. A hand-written constructor's own invariants are not.
The free package catches a missing rule when the test runs: StrictMode(true) makes Generate throw, and AssertConfigurationIsValid checks on demand. Catching it while you type is the Bogus Premium analyzer, which is a paid licence.
No analyzer ships with it. A customization that can never produce a value is found when the test runs.
The compiler accepts any value of the right type — an overlong string, say. Only the domain constructor catches it, at run time.
Do I hand-write a builder for each of my forty domain types?
The constraints for an order are a file somebody has to write, and rewrite the day the type gains a parameter. The question is whether a tool reads your own source and writes it. What it writes is ordinary C# in your test project: read it, edit it, commit it.
Technical term: scaffolding — not a source generator, which runs at build time and leaves you no file
The dum tool reads your type and writes the generator into your test project. The file is ordinary C#, and it is yours to edit and commit.
The same Premium analyzer offers the missing rule as a one-click fix in the editor. That is help of a different shape from a file a tool writes and you keep.
Nothing writes a file for you, and the point is the opposite: with no rules to declare, there is no setup code to write.
You type it. There is nothing to generate.
Three cases where one of the others is the right choice.
Choose Bogus when the data has to look real: names, addresses, emails, a demo database somebody will read. Its catalogue is locale-aware, which is work you would otherwise do by hand. JustDummies draws valid values, not believable ones.
Choose AutoFixture when the test needs a whole object and has nothing to say about what is in it. One call fills the object and everything it holds, including types you did not write. JustDummies starts from the rules; where there are no rules to state, it adds a step and buys nothing.
Write the literal for the value the test is about — the amount an assertion compares against, the status a behaviour turns on. A reader sees the exact value on the line that uses it. A drawn value there would only ask them to take it on trust.
Cases where another tool, or no tool at all, is the better answer.
A demo, a screenshot, a database somebody will browse. Reach for a fake-data generator. A valid value is not a believable one.
Running one assertion over hundreds of generated inputs, then shrinking a failure to its smallest case, is property-based testing. JustDummies draws one value per run, and it is not that tool.
The generators produce test values, not secrets. Nothing drawn here is fit to be used as a credential, in a test or anywhere else.
Add the package to a test project and change one line of one arrangement. Every other test stays as it is. Bogus, AutoFixture, your own builders and every literal you have already written keep working, in the same project and in the same file. If it does not earn its place, backing it out is deleting the lines you added.
Install the library
dotnet add package JustDummies --prereleaseEvery claim about another project on this page comes from that project's own documentation or repository. What was read, and where, is below.
Last checked on August 16, 2026
Read: the locale-aware catalogue (Name, Address, Internet, Commerce), RuleFor and the rules that can be chained on a Faker<T> built inline, the bounded draws such as Random.Int(min, max), StrictMode and AssertConfigurationIsValid, UseSeed and Randomizer.Seed, and the paid Bogus Premium tier whose analyzer flags a missing RuleFor and can insert it.
Read: anonymous rather than realistic values, automatic construction of values of virtually any type, the [Range], [StringLength] and [RegularExpression] annotations honoured with no configuration, the Build<T>().With(...) override, the separate ISpecimenBuilder and Customize<T>() path, and the still-open request for repeatable random values.
The two property-based testing libraries this page points to, for the one criterion none of the four options answers. Both were read to confirm they do what the page says.
If you maintain one of these projects and this page gets it wrong, an issue is the fastest way to have it corrected. Open an issue opens in a new tab