This project is read-only.

Frequently Asked Questions

Where can I read more about AutoFixture?

Currently, ploeh blog serves as documentation repository for AutoFixture. Here are the headlines of the three latest AutoFixture posts:
 ploeh blog - AutoFixture News Feed 
Friday, March 01, 2013  |  From ploeh blog - AutoFixture
 ploeh blog - AutoFixture News Feed 

What is the difference between AutoFixture and Pex? Both projects seem to focus on auto-generating test input.

AutoFixture creates test input for unit tests. That seems to fit the description of Pex pretty well, but despite this superficial similarity, the purpose of these two techonologies is very different.

The purpose of AutoFixture is to create Anonymous Variables while saving you the trouble of doing this manually. It is mainly supposed to be used for Test-Driven Development (TDD), where each test case typically focuses on a single, happy path through the System Under Test (SUT). An underlying tenet of AutoFixture is that although a created Anonymous Variable is unknown at design-time, it is supposed to always take a value that causes the same code path to be exercised every time the test case is executed.

In contrast, Pex focuses on auto-generating a set of test input that in total will exercise every possible permutation of code paths through the SUT. Its main value lies in Quality Assurance (QA) testing, not in TDD.

It would make sense to use a combination of AutoFixture and Pex by using AutoFixture for TDD, and then subsequently Pex for QA.

Is AutoFixture a Dynamic Mock library? It has generic Create methods that seem to 'magically' be able to create instances of a specified type.

Although there are some superficial API similarities between AutoFixture and, say, Rhino Mocks, the purpose and constraints are different.

AutoFixture uses Reflection to create 'well-behaved' instances of public types. It auto-generates instances of other types if necessary to fill in arguments for a constructor, and also assigns values to public writable properties. In essence, it simply uses the requested type's public API to instantiate and populate it. It doesn't do anything that you, as a developer, couldn't do manually - it just does it for you automatically.

In contrast, most Dynamic Mock libraries derive from known types to override the behavior of virtual members. Their purpose is to perform Behavior Verification of the System Under Test (SUT).

Most Dynamic Mock libraries can only mock interfaces and virtual (including abstract) members of unsealed types. AutoFixture doesn't care whether a type is sealed or not, or whether its members are virtual, but it only deals with the public API of the type - as long as the type has a public constructor, it can create an instance if that constructor's arguments can also be created by AutoFixture (recursively).

It's entirely possible, and not particularly uncommon, to use AutoFixture together with a Dynamic Mock library, where AutoFixture is used to create Anonymous Variables that will used in the test, and a Dynamic Mock library is used to verify the behavior of the SUT - often by expecting behavior that involves the Anonymous Variables previously generated by AutoFixture. While this can be configured by hand, AutoFixture can also be turned into an auto-mocking container.

Is AutoFixture a Dependency Injection Container? It has generic Create and Register methods.

The short answer is No, AutoFixture is not a Dependency Injection (DI) Container.

The CreateAnonymous methods are used to create Anonymous Variables based on a relatively simple Reflection-based algorithm. In many cases, AutoFixture can automatically figure out how to create an instance of a requested type, but in some cases, this is not possible - e.g. if a required input variable is of a type that doesn't have a public constructor (such as an interface).

In the case where AutoFixture fails to create an instance because one or more of the dependent types don't have a public constructor, the Register method can be used to specify a custom function that creates an instance that is compatible with that type - e.g. a concrete implementation of an interface.

In such cases, you could argue that AutoFixture acts as its own micro-Container, but its purpose is not to be a general-purpose DI Container.

Does AutoFixture require MSTest or


Although some examples use MSTest or, AutoFixture is built on the core BCL and has no dependencies outside of .NET 3.5. It was originally developed with MSTest, but later migrated to

Last edited Apr 26, 2011 at 7:30 AM by ploeh, version 6


No comments yet.