-
Notifications
You must be signed in to change notification settings - Fork 337
Currently, ploeh blog serves as documentation repository for AutoFixture.
Short code snippets that demonstrate AutoFixture features can be found in Cheat Sheet
You can find generated API documentation version 3.16.5 (unfortunately not the latest) at http://www.nudoq.org/#!/Projects/AutoFixture
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 purposes of the two technologies are very different.
The purpose of AutoFixture is to create auto generated variables (formerly known as Anonymous Variables) to save you the trouble of doing this manually. It is primarily intended to be used for Test-Driven Development (TDD), where each test case typically focuses on a single path through the System Under Test (SUT). An underlying tenet of AutoFixture is that although the value of an auto generated variable is unknown at design-time, it is intended to always receive 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, as an overall set, will exercise every possible permutation of code paths through the SUT. Its main role lies in Quality Assurance (QA) testing, not in TDD.
It can 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, however 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 auto generated variables (formerly known as Anonymous Variables) that will used in the test, and then employ a Dynamic Mock library to verify the behavior of the SUT - often by expecting behavior that involves the Variables previously generated by AutoFixture. While this can be configured by hand, AutoFixture can also be turned into an auto-mocking container.
The short answer is No, AutoFixture is not a Dependency Injection (DI) Container.
The Create methods are used to create auto generated variables (formerly known as 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 is of a type that doesn't have a public constructor (such as an interface).
In the case where AutoFixture would be unable 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 can create 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.
No.
Although some examples use MSTest or xUnit.net, AutoFixture is built on the core BCL and has no dependencies outside of basic framework references/libraries. Its codebase was originally developed with MSTest, but the tests within it were later migrated to xUnit.net.