Why does AutoFixture's AutoMoqData not create mock objects? - unit-testing

Question

I am writing (NUnit) unit tests that target a component of type MyService. Example:
public class MyService : IMyService
{
private readonly IMyRepo _myRepo;
public MyService (IMyRepo myRepo)
{
_myRepo = myRepo;
}
public MyService ()
{
_myRepo = new MyRepo();
}
...
}
I am trying to use AutoFixture as a factory that will generate my test target. I am also trying to have it (AutoFixture) populate my target with mock dependencies (using Moq).
Here's my attempt at doing this:
[Test, AutoMoqData]
public void MyTest(MyService target)
{
...
}
The [AutoMoqData] attribute (based on #ploeh's blog post) extends AutoFixture's [AutoData] attribute with AutoFixture's AutoMoqCustomization feature:
public class AutoMoqDataAttribute : AutoDataAttribute
{
public AutoMoqDataAttribute()
: base(new Fixture()
.Customize(new AutoMoqCustomization()))
{
}
}
When I run unit tests based on the above, I would like to get a real instance of MyService with a Mock<IMyRepo> dependency inside it.
Instead I'm getting a concrete instance of MyRepo.
It seems that AutoMoqCustomization opts to invoke the simplest constructor - the one with no arguments. How can I configure AutoMoqCustomizationto ignore it and instead instantiate the second constructor?
PS - Here is a list of the relevant nuget packages in use:
<package id="AutoFixture" version="3.50.2" targetFramework="net452" />
<package id="AutoFixture.AutoMoq" version="3.50.2" targetFramework="net452" />
<package id="AutoFixture.NUnit3" version="3.50.2" targetFramework="net452" />
<package id="Moq" version="4.5.29" targetFramework="net452" />
<package id="NUnit" version="3.5.0" targetFramework="net452" />

Answer 1

You can try to define a greedy constructor selection algorithm for AutoFixture, but really, the best solution is to remove the parameterless constructor:
public class MyService : IMyService
{
private readonly IMyRepo _myRepo;
public MyService (IMyRepo myRepo)
{
_myRepo = myRepo;
}
}
Having a parameterless constructor is a code smell called Bastard Injection. In most cases, there's no good reason for it.
In my opinion, the best option is to apply the GOOS principle of listening to your tests. When the test becomes difficult to write, it's time to reconsider the design of the System Under Test (SUT). AutoFixture tends to amplify this effect. That's what's happening here.