AutoFixture producing different results under different scenarios

[thatstatsguy]

Hi all

Posting this here as I'm not sure if what I'm seeing is a bug or me just being an Autofixture noob.

I used the quickstart found in the link below as a starting point to setup some tests for an example class.
https://autofixture.github.io/docs/quick-start/#

To produce a minimal working example, I create a new application with dotnet new console -o TestAutoFixture

In it, I've defined a test class called MyService

public class MyService
{
    private readonly string _setting;
    public MyService(IConfiguration configuration)
    {
        _setting = configuration["MySetting"] ?? throw new Exception("Testing");
    }

    public bool TestMethod()
    {
        Console.WriteLine("Hello world");
        return true;
    }
}

What I'm wanting to do is test TestMethod, but the configuration setting is needed for other methods in the class.

Using the aforementioned link, I set up two tests, one using a custom attribute and the other without it.

using AutoFixture;
using AutoFixture.AutoMoq;
using AutoFixture.Xunit2;
using Moq;
using Xunit;


namespace TestAutoFixture.Tests;
public class AutoMoqDataAttribute : AutoDataAttribute
{
    public AutoMoqDataAttribute()
        : base(() => new Fixture().Customize(new AutoMoqCustomization()))
    {
    }
}
public class Tests
{
   //does not pass :( 
    [Theory]
    [AutoMoqData]
    public void AutoMoqTest(
        [Frozen] Mock<IConfiguration> configurationMock,
        MyService service)
    {
        configurationMock
            .Setup(x => x[It.IsAny<string>()])
            .Returns("TestKey");
        
        Assert.True(service.TestMethod());
        
    }
    
    //passes :)
    [Fact]
    public void ManualAutoMoq()
    {
        var fixture = new Fixture().Customize(new AutoMoqCustomization());
        var configurationMock = fixture.Freeze<Mock<IConfiguration>>();
        configurationMock
            .Setup(x => x[It.IsAny<string>()])
            .Returns("TestKey");
        var sut = fixture.Create<MyService>();
        Assert.True(sut.TestMethod());
    }
    
}

The first test fails in the constructor due since no key is found for MySetting. It seems as if the Mock Set method hasn't been picked up.

I'm attaching the details of my .csproj file below - any advice on the above situation? Many thanks for any and all help!

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="AutoFixture" Version="4.18.0" />
    <PackageReference Include="xunit" Version="2.4.1" />
    <PackageReference Include="AutoFixture.AutoMoq" Version="4.18.0" />
    <PackageReference Include="AutoFixture.Xunit2" Version="4.18.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.1.0" />
    <PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="7.0.2" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.4.0" />
   
  </ItemGroup>

</Project>

[aivascu]

@thatstatsguy well you've configured the customization and the attribute just well. The problem is that you're doing more than just initialization in your constructor. Your mock is not yet set up at the moment your service is created.
Basically you're doing the following, in the failing test.

[Fact]
public void ManualAutoMoq()
{
    var fixture = new Fixture().Customize(new AutoMoqCustomization());
    var configurationMock = fixture.Freeze<Mock<IConfiguration>>();
    var sut = fixture.Create<MyService>();

    configurationMock
        .Setup(x => x[It.IsAny<string>()])
        .Returns("TestKey");

    Assert.True(sut.TestMethod());
}

The solution here is to fix your design so that the configuration is not resolved in the constructor but at the moment it is actually used.
Also you might want to start using model binding for configuration instead of injecting IConfiguration.

[thatstatsguy]

Ah of course! Didn't think about the order in which the code was being set up - many thanks @aivascu!