# AutoFixture: anonymous test data for .NET without hand-written object graphs > AutoFixture fills the Arrange phase of .NET unit tests with generated values and object graphs, and the 5.0 line is still in release candidate. Here is what the library does, how to install it, where it stops being the right tool, and how it compares with AutoMoq and Bogus. **AutoFixture/AutoFixture** — AutoFixture is an open source library for .NET designed to minimize the 'Arrange' phase of your unit tests in order to maximize maintainability. Its primary goal is to allow developers to focus on what is being tested rather than how to setup the test scenario, by making it easier to create object graphs containing test data. - Repository: https://github.com/AutoFixture/AutoFixture - Stars: 3,539 · Forks: 358 - Language: C# - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/autofixture-autofixture ## The Arrange-phase tax AutoFixture is built to remove Most unit tests fail for a reason that has nothing to do with the constructor arguments. An API forces you to supply a customer, an order, a list of line items and a configuration object before you can call the one method under test. The values do not matter. They exist so the code compiles, and every time a constructor gains a parameter, every test that built that object by hand needs editing. AutoFixture targets exactly that cost. The README describes its goal as automating non-relevant Test Fixture Setup so the test developer focuses on the essentials of each test case, and it frames the mechanism as anonymous variables plus a generic implementation of the Test Data Builder pattern. The audience is .NET developers practising TDD, particularly those whose suites have grown brittle because Arrange code is duplicated across dozens of tests. If your tests already construct only the two or three values they assert on, the library has little to remove. ## How Create builds an object graph and where customization hooks in The core type is Fixture. Calling fixture.Create() returns an integer, and calling fixture.Create() returns a populated instance, which the README calls a SUT Factory. The same call works for types the library has never seen, because AutoFixture inspects the type and fills its writable members and constructor parameters recursively, producing a graph rather than a single object. The README does not spell out the internal pipeline, so the precise order in which specimens are resolved is not something to assume. What the documentation does state is that behaviour is customizable, and the repository layout supports that: src/ holds the core package and the integration packages, tests/ holds their test projects, and the build is driven by build.cmd, build.ps1 and build.sh with a .nuke directory for the Nuke build definitions. Customization is the extension point you reach for when the default generated value is wrong for a type, for example a string that must be a valid email or an integer that must be positive. The README's cheat sheet, linked from the Overview, is where the concrete customization syntax lives. The second mechanism is the test framework attribute. With the xUnit or NUnit integration, a theory-style test can declare its parameters and let AutoFixture supply them, which the README shows reducing a test to two lines. ## Installing AutoFixture from NuGet and writing a first test AutoFixture ships as NuGet packages. The README gives the .NET CLI form with an explicit version, so the version is pinned rather than floating: ```bash dotnet add package AutoFixture --version 4.18.0 ``` If you prefer to edit the project file directly, the README shows the equivalent PackageReference element: ```xml ``` With the package restored, the smallest useful test creates a Fixture, asks it for a value and a system under test, and asserts that the two interact. The README's introductory example uses an xUnit [Fact] and a class with an Echo method: ```c# [Fact] public void IntroductoryTest() { Fixture fixture = new Fixture(); int expectedNumber = fixture.Create(); MyClass sut = fixture.Create(); int result = sut.Echo(expectedNumber); Assert.Equal(expectedNumber, result); } ``` What you should see is that no literal appears in the Arrange block. The integer and the MyClass instance both come from the fixture, and the assertion compares the echoed value with the generated one. If MyClass has a constructor parameter, AutoFixture supplies that too, which is the point of the graph behaviour described above. The declarative form needs the framework integration on top of the core package. With xUnit the README shows an AutoData attribute supplying both parameters: ```c# [Theory, AutoData] public void IntroductoryTest(int expectedNumber, MyClass sut) { int result = sut.Echo(expectedNumber); Assert.Equal(expectedNumber, result); } ``` NUnit has an equivalent attribute, and the README links a walkthrough for it. The README does not give the exact package name for the xUnit or NUnit integration in the portion reproduced here, so check the NuGet listing before adding one. ## What AutoFixture will not do for you Generated values are anonymous by design, which means they are not meaningful. If a test asserts that a formatted address renders correctly, a generated string will not exercise the formatting rules, and you will end up customizing the fixture until it is a hand-written builder with extra steps. Bogus, which the related searches pair against AutoFixture, takes the opposite approach: it generates realistic, locale-aware data such as names, addresses and phone numbers. The two are not substitutes. AutoFixture removes irrelevant data; Bogus supplies plausible data when the content matters. A second boundary is the 5.0 line. The most recent release in the repository is v5.0.0-rc.1, dated 2026-07-31, and the default branch is release/5.0.0. A release candidate is not a stable release, and the README's install examples still reference 4.18.0. If your organisation requires stable dependencies, 5.0 is not the version to pin yet. Third, the mocking integrations are separate packages with their own release cadence. AutoFixture.AutoMoq is listed in the README's mocking table, and the NSubstitute entry is truncated in the reproduced text, so the set of supported mocking libraries should be confirmed on NuGet rather than assumed from the topic tags, which mention FakeItEasy and Foq as well. Integration packages can lag the core package, and that lag is a real constraint on upgrading. ## AutoMoq, NSubstitute and Bogus: picking the right companion AutoFixture is rarely used alone, and the choice of companion changes what the tests look like. AutoFixture.AutoMoq is the integration for Moq. The README describes these integrations as enabling features such as configuring mocks and auto-injecting mocks. In practice that means an interface in a constructor is filled with a mock instead of failing, so a class with three dependencies can be created without configuring any of them. The trade-off is that the test no longer shows which collaborators exist, and a mock that returns a default value can hide a missing setup. AutoFixture.AutoNSubstitute plays the same role for NSubstitute, and the related searches suggest people compare the two directly; the difference is the mocking library's API and its default behaviour for unstubbed calls, not AutoFixture's generation logic. Bogus is the genuinely different approach. It is a data generator with rules you write, aimed at realistic values, and it does not construct object graphs or act as a SUT factory. A project with a domain of customers and invoices may end up using both: Bogus for the few fields whose values are asserted on, AutoFixture for the surrounding graph. One more integration worth noting is AutoFixture.Idioms, listed as the assertion idioms package. It is a different use of the same library: instead of generating data, it verifies conventions such as guard clauses on a type. That is a distinct reason to add the dependency. ## Version, licence and the cost of keeping up AutoFixture is MIT licensed. The repository carries LICENCE.txt at the top level, and the README's badge links to it. MIT permits commercial use and modification with the licence and copyright notice retained; the usual caveat applies that this is a description of the licence text, not legal advice, and organisations with strict dependency policies should read LICENCE.txt themselves. Upgrade cost has two parts. The core package is versioned independently of the integrations, so a major bump can require coordinated updates across AutoFixture.AutoMoq, AutoFixture.Idioms, AutoFixture.SeedExtensions and the test framework attributes. The 5.0 line has been in preview since at least 2025-01-21 and reached release candidate status on 2026-07-31, which is a long preview cycle; teams that adopted a preview build early should expect to move to the final release when it lands. The repository is not archived, and the last push was on 2026-09-06, so the project is being worked on. That says nothing about the release cadence of any single integration package, which is what determines whether a framework upgrade blocks you. The build entry points (build.cmd on Windows, build.sh elsewhere, with Nuke definitions under .nuke/) matter mainly if you intend to build from source rather than consume NuGet packages. ## Conclusion Adopt AutoFixture if your test suite is dominated by Arrange blocks that exist only to satisfy constructors, and you want a Fixture instance or an AutoData attribute to supply those values. Do not adopt it if you need realistic domain data such as names and addresses, or if you rely on mocking libraries whose integration package is not listed in the README's tables. Before committing, verify that the integration package you need ships for your test framework and that your project can accept the 4.18.0 stable line or the 5.0.0 release candidate, since the default branch is release/5.0.0 and the last push to the repository was on 2026-09-06. ## FAQ ### What is AutoFixture used for in C#? It creates anonymous test data and object graphs so the Arrange phase of a unit test does not have to be hand-written. The README describes its goal as automating non-relevant Test Fixture Setup and offering a generic implementation of the Test Data Builder pattern. ### How do I use AutoFixture? Create a Fixture instance and call Create for the values and the system under test you need. With the test framework integration, an AutoData attribute on a theory-style test can supply the parameters instead, which the README shows for both xUnit and NUnit. ### Is AutoFixture free? Yes. The repository is MIT licensed, with LICENCE.txt at the top level and a licence badge in the README, and the packages are distributed through NuGet. ### What is the difference between AutoFixture and AutoMoq? AutoMoq is an AutoFixture integration package for the Moq mocking library, not a replacement. The README lists AutoFixture.AutoMoq among the integrations that enable configuring mocks and auto-injecting mocks on top of the core Fixture behaviour. ### Is AutoFixture an alternative to Moq or NSubstitute? No. Moq and NSubstitute are mocking libraries, while AutoFixture generates test data and object graphs; the README ships separate integration packages for each of them. You use AutoFixture alongside a mocking library rather than instead of one. ### How does AutoFixture compare with Bogus? They generate different kinds of data. AutoFixture produces anonymous values and fills object graphs so irrelevant setup disappears, while Bogus is aimed at realistic data such as names and addresses. The README does not mention Bogus, so no direct comparison is documented there. ## Sources - [AutoFixture/AutoFixture on GitHub](https://github.com/AutoFixture/AutoFixture) - [Issues](https://github.com/AutoFixture/AutoFixture/issues) - [License: MIT](https://github.com/AutoFixture/AutoFixture/blob/release/5.0.0/LICENSE) - [README](https://github.com/AutoFixture/AutoFixture/blob/release/5.0.0/README.md) - [Releases](https://github.com/AutoFixture/AutoFixture/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/autofixture-autofixture