AutoNSubstitute gives AutoFixture.ObjectCreationException when trying to Build then Create

[bkqc]

I'm trying to create a mock object using AutoNSubstitute but I keep getting the following error:

AutoFixture.ObjectCreationException:
Message=The decorated ISpecimenBuilder could not create a specimen based on the request: MySpace.IEntity. This can happen if the request represents an interface or abstract class; if this is the case, register an ISpecimenBuilder that can create specimens based on the request. If this happens in a strongly typed Build<T> expression, try supplying a factory using one of the IFactoryComposer<T> methods.

The stripped down code I use that crashes is

IFixture _fixture = new Fixture().Customize(new AutoNSubstituteCustomization() { ConfigureMembers = true });
var mock = _fixture.Build<IEntity>().Create();

The target is

var mockCol = _fixture.Build<IEntity>().With(e => e.Code, "0").CreateMany();

I also tried these that do work with the last 2 having their properties correctly filled by AutoFixture

var test1 = _fixture.Build<IEntity>();
var test2 = _fixture.Build<IEntity>().With(e => e.Code, "0");
var test3 = _fixture.Create<IEntity>();
var test4 = _fixture.CreateMany<IEntity>();

Stack of the exception

at AutoFixture.Kernel.NoSpecimenOutputGuard.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.Postprocessor`1.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.CompositeSpecimenBuilder.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.FilteringSpecimenBuilder.Create(Object request, ISpecimenContext context)
at AutoFixture.Dsl.NodeComposer`1.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.CompositeSpecimenBuilder.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.RecursionGuard.Create(Object request, ISpecimenContext context)
at AutoFixture.Dsl.CompositeNodeComposer`1.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.SpecimenContext.Resolve(Object request)
at AutoFixture.Kernel.SeedIgnoringRelay.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.CompositeSpecimenBuilder.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.FilteringSpecimenBuilder.Create(Object request, ISpecimenContext context)
at AutoFixture.Dsl.NodeComposer`1.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.CompositeSpecimenBuilder.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.RecursionGuard.Create(Object request, ISpecimenContext context)
at AutoFixture.Dsl.CompositeNodeComposer`1.Create(Object request, ISpecimenContext context)
at AutoFixture.Kernel.SpecimenContext.Resolve(Object request)
at AutoFixture.SpecimenFactory.Create[T](ISpecimenContext context)
at AutoFixture.SpecimenFactory.Create[T](ISpecimenBuilder builder)
at AutoFixture.SpecimenFactory.Create[T](IPostprocessComposer`1 composer)
at MySpace.Tests.MyTest()

I have also opened a question on StackOverflow with the exact same detail, just in case.

[GeraldLx]

As much as I love AutoFixture, that is the one thing I dont like. The problem you are facing is that you lack the knowledge about what Build does.

I think, when I started with AutoFixture I also wrote a lot of things like this.

Your expectation is that your customization is additional. Basically you want to write code that says "create an IEntity instance with all properties generated automatically, but with Code having the value "0".

The Build method sadly does not work like this. With your setup you told AutoFixture how to generate IEntity instances via NSubstitute. Build starts from scratch. So when you use build, it does not matter if you have setup the customization or not and plain vanilla AutoFixture does not know how to create interfaces.

You have to write your code like this, if you want to use Build:

var entity = fixture.Build<IEntity>()
  .FromFactory(new SubstituteRelay())
  .With(e => e.Code, "0")
  .Create();

Or you could just use the Create method and overwrite the properties, you want to have fixed values for.

Of course AutoFixture is a very open system. There are some advanced ways to achieve what you want, but the 2 approaches I described here are quick and easy to understand.

[aivascu]

@bkqc even though the code snipped from @GeraldLx could work, the scenario you're describing was never supported by AutoFixture. As soon as you'll have property with only a getter and no setter the SubstituteRelay workaround is no longer going to be an option.

AutoFixture intentionally delegates the responsibility for creating mocks to mocking frameworks, since they have custom APIs to set up the instances which is too complex to build around and maintain.

My suggestion is to create a fake implementation of the interface and use that to setup valid IEntity instances.
From the perspective of the client code there should be no difference if it's a dynamic proxy or a specific class.

[bkqc]

Thanks for your inputs but finally, since the first proposition is incomplete from what I understand of @aivascu answer and the second one means maintaining this implementation, I ended up removing AutoFixture from the equation and instead simply use LinQ with NSubstitute:

var mockCol = Enumerable.Repeat(0, 3).Select(_ => { var ret = Substitute.For<IEntity>(); ret.Code = "0"; return ret; });

I suppose the best solution, if it is possible, would be for AutoNSubstitute to implement a With that would do an assignment if it is R/W or a .Returns() if R/O but considering my very small use case, I won't dig deeper into the problem for now.

[bkqc]

@GeraldLx , I don't have deep knowledge of AutoFixture but from what I saw in the source code, isn't your proposition identical, as far as the end result is concerned, to defining AutoNSubstituteCustomization of the fixture? How exactly is your proposed solution working? What does it do?

[GeraldLx]

I tried to explain it in my initial post here, but I can try again ;)

AutoFixture can create certain types out of the box, like strings etc.
What AutoFixture cannot create is e.g. an abstract class or an interface.

When you request a type from AutoFixture, AutoFixture checks internally which part of the configuration can create the type.

So when you add the AutoNSubstitute configuration, you basically extend the AutoFixture configuration to make the creation of abstract classes and interfaces possible.

So with the customization in place, you can successfully run this code:

var entity = fixture.Create<IEntity>();

This gives a fully created entity with all members set.

What you tried to achieve was building an object with AutoFixture. When you do this, you do not use any customizations. You start from scratch generating a new object. Therefore with or without the customization AutoFixture has no clue how to build an IEntity instance. You can add the creation logic by using the FromFactory method. This method has a few overloads.

So the simplest approach for your problem could be:

var entity = fixture.Build<IEntity>()
  .FromFactory(() => Substitute.For<IEntity>())
  .With(e => e.Code, "0")
  .Create();

Another overload takes a specimen builder instance. So instead of calling Substitute.For myself, my code used the component from the customization library. In simple cases both code snippets lead to the same result.

But as @aivascu already said, the simple solution only works for properties with setters. The SubstituteRelay also gives random values to readonly properties.

The same goes for the With statement. You cannot use it for readonly properties, cause sadly this is hard coded in AutoFixture. There is no way to tell AutoFixture "hey, I have a customization that can do that".

So unless you dont want to go very deep into AutoFixture and dont have the need to make your tests free of NSubstitute referenes, I would advice to write your tests more like this:

var entity = fixture.Create<IEntity>();
entity.Code = 0;

or

var entity = fixture.Create<IEntity>();
entity.Code.Returns(0);

for readonly properties.

Then you can use the customization and let AutoFixture create the substitutes. Any unwanted randomization you just overwrite.

[bkqc]

Wow, thanks @GeraldLx! This is an awesome explanation. Thank you so much! Something like this should go into the official documentation to help understand the Build behaviour!

However, I don't understand the part where you say that using your last snippets would prevent from having NSubstitute references in my tests. AutoNSubstitute needs a reference to NSubstitute (though it is not shown if using PackageReference but I would also not have control on the version used) and Using NSubstitute is, AFAIK, needed to use the Returns(0) extension method. And in that case, it would look like I could still use my proposed solution. So I take it that your final point is to try to keep only one mocking language inside a given test code project, right?

[GeraldLx]

Sorry for the late reply, but I was in vacation ;)

Some guys like to reduce the dependencies as much as possible. So in theory you could stick with the in build AutoFixture options by passing in the ISpecimenBuilder instance to your tests. So in the case of NSubstitute it would be only the SubstituteRelay.

That would make your tests open to using other mocking frameworks in the future.

Personally I would not go this route. It feels a little bit like old days, when everyone wanted to be database agnostic to have the option to change the database, which 99,9 percent never did.

The reason was mainly due to the fact you started this whole Build / With construct making things a little more complicated, but independent of NSubstitute.

As said, I use the practical version with the Create and then Returns, but if you dont like it, there are ways to avoid this.