AutoFixture.ObjectCreationExceptionWithPath after moving to AutoFixture 4.0+

[bkqc]

Hi,
I know I'm late to the party but you know how so companies may be slow to move the boat...
I actually have all my tests are configured to use AutoFixture v3.51 and are working as expected.
To be able to use new features from AF and helpers NuGets, we want to move forward in our versions so I first moved to 4.2.1 I started to get
AutoFixture.ObjectCreationExceptionWithPath: AutoFixture was unable to create an instance from System.Collections.IEnumerable because it's an interface.
errors so I moved back to 3.5.1 to make sure and everything passed again. I then tried to upgrade to the right next available version: 4.0.0 but got the same error.

I read the Release Notes 3 times about 4.0.0 but can't find anything that seems to explain the problem I'm facing.
How can I know which constructor argument or property is the problem? Why was it working in 3.5.1?

The complete error was

    La méthode de test MyTestClass.MyTestMethod() a levé une exception : 
AutoFixture.ObjectCreationExceptionWithPath: AutoFixture was unable to create an instance from System.Collections.IEnumerable because it's an interface. There's no single, most appropriate way to create an object implementing the interface, but you can help AutoFixture figure it out.

If you have a concrete class implementing the interface, you can map the interface to that class:

fixture.Customizations.Add(
    new TypeRelay(
        typeof(System.Collections.IEnumerable),
        typeof(YourConcreteImplementation)));

Alternatively, you can turn AutoFixture into an Auto-Mocking Container using your favourite dynamic mocking library, such as Moq, FakeItEasy, NSubstitute, and others. As an example, to use Moq, you can customize AutoFixture like this:

fixture.Customize(new AutoMoqCustomization());

See http://blog.ploeh.dk/2010/08/19/AutoFixtureasanauto-mockingcontainer for more details.

Request path:
	System.Web.Mvc.SelectList SortingProperties
	  System.Web.Mvc.SelectList
	    System.Collections.IEnumerable items
	      System.Collections.IEnumerable

Thank you :)

[aivascu]

@bkqc can you provide a minimum reproducible example?
It would be useful to see what the class looks like and how you customize the fixture.
Also please try upgrading to the lastest v4.x version, as multiple bug fixes and features have been added since v4.2.1

[bkqc]

I wanted to take small step to limit the amount of breaking changes but if you're quite sure there aren't any except for Ploeh.AutoFixture, I'll give it a try.

[aivascu]

@bkqc the versioning model of AutoFixture ensures that there are no breaking changes within the same major version. Well except for bugs if any are present.
If you are still encountering the issue please post an example of code that doesn't work. From the information you provided it's hard to figure out why this is happening.

[Ergamon]

I have no clue what you were changing, but it must be something more than just upgrading the version of AutoFixture.

The problem is the class SelectList from the Microsoft.AspNet.Mvc package.

I made a .NET Framework console app and added the following NuGet packages:
AutoFixture 4.18.0
Microsoft.AspNet.Mvc 5.2.9

When I run the following code:

var fixture = new Fixture();
var list = fixture.Create<SelectList>();

I get the same error you posted, but a downgrade to AutoFixture 3.51.0 changes nothing. Still the same error.

If you look at the source for the class, you can easily spot the problem:

    public SelectList(IEnumerable items)
      : this(items, null)
    {
    }

The class has a ctor taking an IEnumerable. There is no type supplied, so basically the constructor takes anything that can be iterated over. So you must help AutoFixture to supply a solution for this.

I am quite sure that your old code had some kind of customization that has been lost in the upgrade process.

[bkqc]

Trying to create the smallest solution possible having the problem, I think I found where the problem is coming from but not why.
In my Init method, I do (the cast was added to remove CS0121 with 4.18)

_fixture.Customize<ListeCommunicationModel>(x => x
    .With(y => y.SortingProperties, (System.Web.Mvc.SelectList) null));

With or without the cast, it works in 3.51 but crashed in 4.0.0 and 4.18 on

_ = _fixture.Build<ListeCommunicationModel>()
    .Create();

The project is attached here. Note that the implementation projet is in 4.5.2 and the test project, 4.8 though I don't think it has an any influence.
AutoFixture4Demo.Tests.zip

[Ergamon]

I looked up your code. Sadly I am not using AutoFixture long enough to explain, why it worked in the old version.

But the good news is, that there is an easy fix.

First of all you have the problem with the SelectList as I have posted before. You are not creating a SelectList explicitly, but one of your classes has this type as a property with a setter. So AutoFixture will normally create it.

_fixture.Customize<ListeCommunicationModel>(x => x
    .With(y => y.SortingProperties, (System.Web.Mvc.SelectList) null));

can be simplified to

_fixture.Customize<ListeCommunicationModel>(c => c.Without(m => m.SortingProperties));

But that does not solve the problem. The main problem is this:

_ = _fixture.Build<ListeCommunicationModel>().Create();

Basically Build and Customize are for the same thing. Customize changes the way for every ListeCommunicationModel that will be created by the fixture, while Build allows you to create a special version of the type. Basically it is a one time customization.

Sadly customizations dont add up. (Maybe this was the case in older versions?)

So your code basically changes the way AutoFixture handles creating ListeCommunicationModel. But then you say, but for this instance build it the default way.

So you can either delete the customization code and add the With/Without statement to the Build chain:

_ = _fixture.Build<ListeCommunicationModel>().Without(m => m.SortingProperties).Create();

Or keep the customization and just create the instance by:

_ = _fixture.Create<ListeCommunicationModel>();

[bkqc]

The thing is, this is a very simplified version of the test. The real one does many more local customizations so simply calling Create is not an option. As for the other use, this would mean modifying 10s or 100s of code with repetitive code. Maybe there is someone that was there back in the time that could explain why the behaviour changed? @aivascu ?

[bkqc]

On a side note, is .Without nullable-reference aware? Actually, if I try to assign null to a non nullable reference type, I will have a warning forcing me to mark it as such with null!.

[Ergamon]

I started to read the Changelog for v4. Seems a little tragic for you. I could not find anything explaining the changed behavior in the breaking changes list.

The reason it works in the old AutoFixture version was a bug. As I explained before. Customize changes the way Create works. If you start with Build, you ignore what Customize did.

If you check here:
https://github.com/AutoFixture/AutoFixture/wiki/v4.0-Release-Notes

You can find
Fix one customization could affect other customizations

So basically your tests seem to rely on this bug.

It is hard to give good advices, if I dont know the problems. If all your problems are just related to SelectList, you could solve this by a customization for this type.

[bkqc]

Unfortunately, it is not only SelectList that has this kind of preset behaviour.
What would be a right way then to have a default Build behaviour but personalize only some specific properties to direct the sut execution path?

[Ergamon]

I dont get your Without question. Considering that you compile your projects with enabled Nullable, then there is nothing special about AutoFixture.

Considering a class like this:

public class Message
{
  public string? Subject { get; set; }

  required public string Body { get; init; }
}

You can create it with AutoFixture e.g.:

    var fixture = new Fixture();
    fixture.Build<Message>()
      .With(m => m.Subject, (string?)null)
      .With(m => m.Body, (string)null)
      .Create();

And of course you will get a warning about the null value for Body. After all it is declared as non nullable.

But this has nothing to do with AutoFixture.

    var message = new Message
    {
      Subject = null,
      Body = null,
    };

will do exaclty the same as the AutoFixture code and produce exactly the same warning.

Without is just a way to tell AutoFixture to completly ignore the property. So noting is special about nullable properties.

(The confusing part about developers exploring the nullable reference type feature is, that this is just a C# feature. You are basically telling the compiler, that you dont want null values for this property. Therefore you get warnings, if you do so. But technically reference types can always be null. Therefore you can set them to null. The ! just tells the compiler to shut up and suppress the warning)

[bkqc]

I agree with your conclusion about the fact it is simply compiler sugar, not runtime checks but still, having the ! does not only suppress the warning but also expresses the fact that the developer asserts it is ok to do so (like when testing what would happen if a null-ref unaware piece of code would call our method or if some code simply ignored the warning).

And about Without, it's true that if we look at it from the angle of

Without is just a way to tell AutoFixture to completly ignore the property

there is nothing special to do about null-refs but it also means it is not exactly the same as With(=>, null!) since if my object sets a default value, Without will have that value and not a null reference.

Thanks for shedding more light on this :)

[aivascu]

@bkqc as @Ergamon mentioned the behavior you used to rely on was a bug, which was fixed back in 2017. The same syntax you used to apply will not work in latest version. You can see the reason begin the fix in the PR #781. As far as I can tell the reason was the necessity to isolate composition graphs for polymorphic types, as well as tests that needed to customize the same type multiple times (override previous customization).

Not sure if this will help, but a while back I put together this custom implementation for reusing post-processing expressions. It should allow you to encapsulate what you previously had inside the Customize<T> expressions and reuse them in your Build<T> expressions.

public class ModelWithoutSortingProperties : IPartialPostprocessComposer<ListeCommunicationModel>
{
    public IPostprocessComposer<ListeCommunicationModel> Compose(IPostprocessComposer<ListeCommunicationModel> composer)
    {
        return composer.Without(y => y.SortingProperties);
    }
}

[TestMethod]
public void Foo()
{
    _ = _fixture.Build<ListeCommunicationModel>()
        .Using(new ModelWithoutSortingProperties())
        .With(x => x.SomeOtherProperty, "Some value")
        .Create();
}

You're still going to have update your entire test suite, but these changes should be less invasive.

On a side note, is .Without nullable-reference aware? Actually, if I try to assign null to a non nullable reference type, I will have a warning forcing me to mark it as such with null!.

.Without is not nullable-aware, it just skips setting any value to that member (property/field). So the member will be set to whatever would have been the value if you just new the object. If you have a default initializer for that member it will be that value.
I don't think the compiler is smart enough to realize the object will be created without any value set to it, so there should not be any compile-time errors/warnings. If you need a value for a non-nullable reference type just don't apply .Without to it.

[bkqc]

Considering the time it took to isolate the problem (or maybe it is me that works slowly :P), could I suggest that this is added to the Breaking Changes section of the v4 Release Notes?

[bkqc]

So I used an implementation similar to what @aivascu suggested and it works fine for objects that are superficially customized but what if I want to have every instance of a given nested type created a specific way but some properties of a superficial one specfici to a given test?

For instance

Type1
|- Type2[]
|   |_ Type3
|       |_ CustomizedPropertyValue
|- Type4
|   |_ Type3[]
|       |_ CustomizedPropertyValue
|_ WithPropertyValue (using IPostprocessComposer)

From what I understand right now of the new behaviour, I would have to add With clauses to CreateMany Type2 which would call Build with another With to Build Type3 and repeat the process for Type4 and every nested instance of the Type3 array and so on if I got it nested elsewhere or worse, deeper.

This looks like a lot of work for something that used to be simple. Isn't there a way to scope a sub fixture from a parent one for instance or tell Build to import parent Customization maybe?

[aivascu]

@bkqc well the IPostprocessComposer in Build<T> is the option offered by AutoFixture to create a scope around an explicit object creation. If you're asking about the possibility to create a child Fixture then the answer is no. By design there should always be just one fixture instance, that's customized to create objects for a specific scenario. No one is stopping you from creating clones of the Fixture if you can/want, but this is not something AutoFixture was built around.

Assuming a type structure similar to one that you've shown above, your type customization would look something like below.
You can probably make it shorted by applying the reuse pattern I've provided in the previous answer.

[Fact]
public void Foo()
{
    var fixture = new Fixture();

    fixture.Customize<TypeA>(c => c
        .With(x => x.Prop1, "Custom Prop 1")
        .With(x => x.PropB, (IFixture f) => f.Build<TypeB>()
            .With(y => y.PropC1, (IFixture f) => f.Build<TypeC>()
                .With(z => z.Prop1, "Type C Value 1")
                .Create())
            .CreateMany().ToArray())
        .With(x => x.PropD, (IFixture f) => f.Build<TypeD>()
            .With(y => y.PropC2, (IFixture f) => f.Build<TypeC>()
                .With(z => z.Prop1, "Type C Value 2")
                .CreateMany().ToArray())
            .Create()));

    var data = fixture.CreateMany<TypeA>();

    Assert.All(data, item =>
    {
        Assert.Equal("Custom Prop 1", item.Prop1);
        Assert.All(item.PropB, item2 => Assert.Equal("Type C Value 1", item2.PropC1.Prop1));
        Assert.All(item.PropD.PropC2, item3 => Assert.Equal("Type C Value 2", item3.Prop1));
    });
}

Is this lengthier? Probably, yes.
Is it better? It's probably a matter of perspective. As I see it, this is much clearer than to try to understand which customizations will be applied considering you might have polymorphic types, and it is definitely better than writing factories by hand.
Is it easier? Probably, no. The rule of thumb I apply in my code bases is that if I can't test my code easily then probably my design is flawed.

Either way this behavior won't change back since it would re-introduce the problems from v3. We are trying to maintain backward compatibility as much as possible, but there are breaking changes and there will be more in the following major versions.

[bkqc]

Then maybe adding a new method to the IPostProcessComposer (the Build) to customize a Type for the current composer (not a specific property of an instance) could be a nice addition that could potentially shorten the build code a lot when we need a specific default way of building objects while fine tuning only a couple properties with With statements?