Question

I’m looking to customize the creation-time behavior of AutoFixture such that I can set up some dependent objects after the properties of the fixture have been generated and assigned.

For example, suppose I have a method that customizes a User because its IsDeleted property always has to be false for a certain set of tests:

public class User
{
   public int Id { get; set; }
   public string Name { get; set; }
   public bool IsDeleted { get; set; }
}

public static ObjectBuilder<User> BuildUser(this Fixture f)
{
   return f.Build<User>().With(u => u.IsDeleted, false);
}

(I hand an ObjectBuilder back to the test so it can further customize the fixture if necessary.)

What I’d like to do is automatically associate that user with an anonymous collection by its Id at creation time, but I can’t do this as-is because Id has not been generated by the time I hand the return value back to the unit test proper. Here’s the sort of thing I’m trying to do:

public static ObjectBuilder<User> BuildUserIn(this Fixture f, UserCollection uc)
{
   return f.Build<User>()
           .With(u => u.IsDeleted, false);
           .AfterCreation(u =>
            {
               var relation = f.Build<UserCollectionMembership>()
                               .With(ucm => ucm.UserCollectionId, uc.Id)
                               .With(ucm => ucm.UserId, u.Id)
                               .CreateAnonymous();
               Repository.Install(relation);
            }
}

Is something like this possible? Or perhaps there is a better way to accomplish my goal of creating an anonymous object graph?

Answer 1

For the Build method, this isn’t possible, and probably never will be, because there are much better options available.

First of all, it should never be necessary to write static helper methods around the Build method. The Build method is for truly one-off initializations where one needs to define property or field values before the fact.

I.e. imagine a class like this:

public class MyClass
{
    private string txt;

    public string SomeWeirdText
    {
        get { return this.txt; }
        set
        {
            if (value != "bar")
                throw new ArgumentException();
            this.txt = value;
        }
    }
}

In this (contrived) example, a straight fixture.CreateAnonymous<MyClass> is going to throw because it’s going to attempt to assign something other than “bar” to the property.

In a one-off scenario, one can use the Build method to escape this problem. One example is simply to set the value explicitly to “bar”:

var mc =
    fixture.Build<MyClass>().With(x => x.SomeWeirdText, "bar").CreateAnonymous();

However, even easier would be to just omit that property:

var mc =
    fixture.Build<MyClass>().Without(x => x.SomeWeirdText).CreateAnonymous();

However, once you start wanting to do this repeatedly, there are better options. AutoFixture has a very sophisticated and customizable engine for defining how things get created.

As a start, one could start by moving the omission of the property into a customization, like this:

fixture.Customize<MyClass>(c => c.Without(x => x.SomeWeirdText));

Now, whenever the fixture creates an instance of MyClass, it’s just going to skip that property altogether. You can still assign a value afterwards:

var mc = fixture.CreateAnonymous<MyClass>();
my.SomeWeirdText = "bar";

If you want something more sophisticated, you can implement a custom ISpecimenBuilder. If you want to run some custom code after the instance has been created, you can decorate your own ISpecimenBuilder with a Postprocessor and supply a delegate. That might look something like this:

fixture.Customizations.Add(
    new Postprocessor(yourCustomSpecimenBuilder, obj =>
        { */ do something to obj here */ }));

(BTW, are you still on AutoFixture 1.0? IIRC, there hasn’t been an ObjectBuilder<T> around since then…)