DataSourceGeneratorAttribute query with autofixture and frozen constructs

[WestDiscGolf]

Hi,

I've been playing around with TUnit and finding it pretty cool. Great usage of the new generic attributes etc.

I have however come across a scenario I can't work out how to get around and that is similar construct to the InlineAutoData which uses Autofixture and the xUnit data attributes.

The scenario appears to be a combination of the ArgumentsAttribute usage, the method data sources and the DataSourceGenerators<>.

Using my recent blog post for examples to work through - https://adamstorr.co.uk/blog/autofixture-and-ioptions-a-winning-combination/ - I have managed to work though all the scenarios until I get to options 6 when it starts to abstract out the AutoFixture setup etc.

I have tried

[InlineAutoMoqData]
public class TestServiceTestsWithSpecialSauce(TestService sut)
{
    [Test]
    public async Task Test()
    {
        var name = sut.Name;

    }

With the attribute definition

public class InlineAutoMoqDataAttribute : TestDataAttribute, IDataAttribute
{
    public IEnumerable<object> GenerateDataSources(DataGeneratorMetadata dataGeneratorMetadata)
    {
        var fixture = new Fixture();

        fixture.Customize(new AutoMoqCustomization());
        fixture.Customizations.Add(new OptionsSpecificationBuilder());

        yield return new TestService(null!);       // temp return
    }
}

The thought process being I could look at the dataGeneratorMetadata and interrogate the details of the ParameterInfo details passed in. But this doesn't work and the test doesn't seem to register in the runner.

I then tried an implementation of the DataSourceGenerator:

public class TestServiceGeneratorAttribute : DataSourceGeneratorAttribute<TestService>
{
    public override IEnumerable<TestService> GenerateDataSources(DataGeneratorMetadata metadata)
    {
        var fixture = new Fixture();

        fixture.Customize(new AutoMoqCustomization());
        fixture.Customizations.Add(new OptionsSpecificationBuilder());

        yield return fixture.Create<TestService>();
    }
}

And this does create the required instantiation of the TestService which is good. But I can't extend the dependencies to say I optionally want access to the Frozen dependency so I can reference it in the test scenario.

I've had a look at the IClassConstructor constructs and can't see how this would fit either.

The api surface I am currently thinking would be something like ...

[DependencyGenerator]
public class TestServiceTestsWithSpecialSauce(TestService sut, [Frozen] IOptions<TestOptions> options)
{
    [Test]
    [Arguments(1, "hello")]
    public async Task Test(int id, string value)
    {
        var name = sut.Name;

        name.Should().Be(options.Value.Name);
    }
}

Allows you to specify the class level details for the service under test and reference any class level structures or instantiate items or reference marking a mock as frozen etc. Then at each test scenario in the class you could specify values as required.

It's quite a common pattern for a lot of tests which I write to try and reduce duplication of boilerplate code. Is this a scenario which could be supported? Is there a way today that I can write this?

Thanks again 😎

[thomhurst]

I don't think I quite follow fully.

Does this not do what you need?

[TestServiceGenerator]
public class TestServiceTestsWithSpecialSauce(TestService sut, [Frozen] IOptions<TestOptions> options)
{
    [Test]
    [Arguments(1, "hello")]
    public void Test(int id, string value)
    {
        var name = sut.Name;

        name.Should().Be(options.Value.Name);
    }
}

public class TestServiceGeneratorAttribute : DataSourceGeneratorAttribute<TestService, IOptions<TestOptions>>
{
    private readonly Fixture _fixture;

    public TestServiceGeneratorAttribute()
    {
        _fixture = new Fixture();
        _fixture.Customize(new AutoMoqCustomization());
        _fixture.Customizations.Add(new OptionsSpecificationBuilder());
    }
    
    public override IEnumerable<(TestService, IOptions<TestOptions>)> GenerateDataSources(DataGeneratorMetadata metadata)
    {
        var options = metadata.ParameterInfos!.ElementAt(1).ParameterType.GetCustomAttribute<FrozenAttribute>() != null
        ? _fixture.Freeze<IOptions<TestOptions>>()
        : _fixture.Create<IOptions<TestOptions>>();

        var testService = _fixture.Create<TestService>();
        
        yield return (testService, options);
    }
}

public class OptionsSpecificationBuilder : ISpecimenBuilder
{
    public object Create(object request, ISpecimenContext context)
    {
        // determine if it's what we are looking for
        if (request is Type type 
            && type.IsGenericType 
            && type.GetGenericTypeDefinition() == typeof(IOptions<>))
        {
            // determine the type of options you want to create
            var typeOfOptions = type.GetGenericArguments()[0];

            // get autofixture to resolve an instance for you using the default creation routines
            var instance = context.Resolve(typeOfOptions);
            
            // determine the type and through generics get access to the generic version of the method. You can't call it directly otherwise
            // at runtime it behaves like it is an IOptions<object> which is not what you are looking for.
            var optionsCreateMethod = typeof(Options).GetMethod(nameof(Options.Create))?.MakeGenericMethod(typeOfOptions);

            // call the method, if available, with the instance resolved above. This is equivalent to Options.Create<typeOfOptions>(instance)
            var optionsInstance = optionsCreateMethod?.Invoke(null, new[] { instance });

            // return if possible, otherwise return no specimen
            return optionsInstance ?? new NoSpecimen();
        }

        return new NoSpecimen();
    }
}

[WestDiscGolf]

Thanks for taking the time to reply.

Conceptually I believe this would work. However as the dependency count got larger or the codebase of items to test increased, if I've understood the solution properly, there would end up being a lot of boiler plate code in derived implementations of DataSourceGeneratorAttribute. The power of the xUnit constructs is that if you add a new dependency to the SUT then it will continue to work unless you need access to it in the tests. But also allows you to add the new dependency, either a mock or otherwise, into the parameters and it will wire it up automatically. In the suggested route it would require a change to the DataSourceGenerator constructs, add in additional generic parameters etc. each time. But maybe that's ok 🤔

Using your example as starting point I will continue to play to see what I can come up with and get back to you :-)