I am trying to use autofixture to create an object but there are certain properties that I want to always be defaulted (while the rest could be auto generated). However, wheneve
This looks like it's by design:
Note that the Build method chain is best understood as a one-off Customization. It bypasses all Customizations on the
Fixture
instance. Instead, it allows fine-grained control when building a specific specimen. However, in most cases, adding a convention-basedICustomization
is a better, more flexible option.
...from the Build()
method's documentation.
I appreciate that this is probably not an ideal answer. However, the documentation does provide a hint as to how you might arrive at one.
As noted by the accepted answer Customizations will override each other, so you would have to write a customization for every combination of properties you'd want to use.
I wrote a library that allows you to compose Customizations so that they don't override each other but rather get merged together. This would allow you to have one Customization for People named Ben
and one for Born in 1900
, and you can compose them together with the Compose function.
It doesn't quite address the original question, but it may give you some ideas on how to achieve what you want. The Compose function is accomplished by creating a custom IFixture implementation that handles the customizations.
https://github.com/LethargicDeveloper/Lift.AutoFixture
EDIT: I saw "active 4 months ago." I missed the "3 years." Sorry for resurrecting such an old post, but hopefully this will be useful.
As @DavidOsborne correctly pointed out, the behavior you are seeing is as designed.
A better approach is to organize your customizations in separate classes and then enable them as needed by a specific test scenario.
A customization object implements the ICustomization
interface and its job is to configure the Fixture
object in a specific way. Here's an example:
public class AllPersonsAreNamedBen : ICustomization
{
public void Customize(IFixture fixture)
{
fixture.Customize<Person>(composer =>
composer.With(p => p.Name, "Ben"));
}
}
public class AllPersonsAreBornIn1900 : ICustomization
{
public void Customize(IFixture fixture)
{
fixture.Customize<Person>(composer =>
composer.With(p => p.DateOfBirth, new DateTime(1900, 1, 1)));
}
}
You can enable a customization on a specific Fixture
by using the Customize
method, for example:
fixture.Customize(new AllPersonsAreNamedBen());
or:
fixture.Customize(new AllPersonsAreBornIn1900());
You can also combine multiple customizations into a new one by using the CompositeCustomization
class:
public class AllPersonsAreNamedBenAndAreBornIn1900 : CompositeCustomization
{
public AllPersonsAreNamedBenAndAreBornIn1900()
: base(new AllPersonsAreNamedBen(),
new AllPersonsAreBornIn1900())
{
}
}
at which point you can simply say:
fixture.Customize(new AllPersonsAreNamedBenAndAreBornIn1900());
However, keep in mind that the order in which the customizations are applied on a Fixture
matters: the last one wins and can potentially override the previous ones, as @MarkSeemann pointed out in the comments. This, too, is by design.
So, while you can combine existing customizations that work on different types, in this particular case, since both customizations target the same type, you'll have to create a new customization to encapsulate all the settings for the Person
type combined:
public class AllPersonsAreNamedBenAndAreBornIn1900 : CompositeCustomization
{
public void Customize(IFixture fixture)
{
fixture.Customize<Person>(composer =>
composer.With(p => p.Name, "Ben")
.With(p => p.DateOfBirth, new DateTime(1900, 1, 1)));
}
}
As a general rule, keeping your customizations small and focused enables you to reuse them in different tests, combining them for specific test scenarios.