Customization ejection (aka Unfreezing)

[aivascu]

Unfreezing has been a frequently requested feature. This issue is aimed to consolidate the discussions around the requirements, the API and the necessity of this feature.

The common requested trait was that the Fixture should allow to revert a previous request to Freeze / Inject / Register / Customize a type request.

Explicit customization ejection

Since .Freeze<T>(), .Inject<T>(), .Register<T>() and .Customize<T>() are loosely performing the same actions, it makes sense for them to have the same reset action. This common action could potentially be performed by a .Eject<T>() (the name to be defined) method on the Fixture class.

Proposed API

var frozen = fixture.Freeze<string>(); // random string 1

var value1 = fixture.Create<string>(); // random string 1

fixture.Eject<string>();

var value2 = fixture.Create<string>(); // random string 2

fixture.Inject<string>("hello world!"); // hello world!

var value1 = fixture.Create<string>(); // hello world!

fixture.Eject<string>();

var value2 = fixture.Create<string>(); // random string 1

fixture.Customize<ValueHolder<string>>(
    c => c.With(x => x.Property, "hello world!")); // hello world!

var value1 = fixture.Create<ValueHolder<string>>(); // hello world!

fixture.Eject<ValueHolder<string>>();

var value2 = fixture.Create<ValueHolder<string>>(); // random string 1

Auto-Ejecting customization

Another often requested aspect of the "ejection" is usually a customization reset after a condition has been met. Usually after the first successful resolution of an instance using the customization.

Proposed API

fixture.Inject<string>("hello world!", Resolve.Once));

var value1 = fixture.Create<string>(); // hello world!
var value2 = fixture.Create<string>(); // random string 1

var frozen = fixture.Freeze<string>(Resolve.Exactly(2));

var value1 = fixture.Create<string>(); // random string 1
var value2 = fixture.Create<string>(); // random string 1
var value3 = fixture.Create<string>(); // random string 2

var frozen = fixture.Freeze<string>(Resolve.After(1).Exactly(2));

var value1 = fixture.Create<string>(); // random string 1
var value2 = fixture.Create<string>(); // random string 2
var value3 = fixture.Create<string>(); // random string 2

[isberg]

@aivascu I was just thinking today that I really like the ability to unfreeze. Makes sence to me with a common operation. How can I aid in moving this feature along. I believe unfreezing something frozen should be pretty straight forward, not sure about the temporary freezing case, except that it seems handy.

[aivascu]

@isberg since I posted this thread, I have experienced a slight change of heart, for this feature. At this point I am not so sure an unfreeze feature should exist. The more I used AutoFixture the more I started to treat it as a toolset for building data generators. In that context you don't really need to remove anything, you just have to build the thing that generates the data you require.

That said a very basic unfreeze/eject feature is fairly simple to implement. By default each time you customize a type inside a Fixture you actually you inject a customization that is being processed before all other customizations (unless you inject it somewhere in the middle).
The type of this customization is NodeComposer<T>. This customization type is used for Freeze, Inject, Register and Customize<T>.
So unfreezing is simply an action of removing said customization from the Fixture.
Here's a basic example:

public static void Eject<T>(this Fixture fixture)
{
    var composer = fixture.Customizations.FirstOrDefault(x => x is NodeComposer<T>);
    if (composer == null)
        return;
    fixture.Customizations.Remove(composer);
}

There is one big issue with this implementation. What happens if the users have created their own NodeComposer implementations? Or what if the users have frozen the values in some other way. In that case it is nearly impossible to identify the node that needs to be removed in order to eject the type customization.
To reliably be able to unfreeze a value, would require to change the design of AutoFixture in a way that would impact its flexibility.
So yeah, at this point I'll need a compelling use case to consider this feature.

[mrukas]

I know that this is an old topic but I have a question.
Lets say i freezed a DbContext to simulate scoped service lifetime. How am I able to create a new instance of my DbContext class later on. Do in need to create a completely new fixture?

[aivascu]

@mrukas sounds like an issue with the scope of the test tbh. Could you provide a code snippet showing how you'd like to write that test and what it would do?

[mrukas]

@aivascu Thanks for your fast response!

For my DbContexts I am using an adapted version of EntityFrameworkCore.AutoFixture.

For my tests its better for my DbContext objects to be singletons for the scope of that single test method, because it's more similar to the way ASP.NET Core would use the DbContext (scoped lifetime, one instance per request). Therefore I am using an own AutoDataAttribute that creates the fixture and uses an DbContext instance created by the fixture to seed the database with generic stuff before the test. In the test method i use a seeder to seed more test specific data. After using some of my service methods, i use a new instance of the DbContext to check if some entries exist (Assert phase). The problem is that i can't create a new instance of the DbContext in the assert phase this way.

My ideas would be to manually create the context afterwards and only let autofixture resolve the dependencies. Another way would be to clear the ChangeTracker, but both methods seem a little bit strange to me.

Code example:

[Theory, AutoDomainData]
public async Task MyTestMethod(IFixture fixture)
{
    // Arrange
    await fixture.SeedDatabaseAsync<ApplicationDbContext, MyTestSeeder>();

    //Act
    var exampleService = fixture.Create<ExampleService>();
    await exampleService.CallTestmethod();

    // Assert
    var dbContextToCheck = fixture.Create<ApplicationDbContext>();
    var reloadedEntries = await dbContextToCheck.TestEntries.ToListAsync();
    reloadedEntries.Should().AllSatisfy(x => x.ValueToCheck.Should().Be(0.5));
}

SeedDatabaseAsync is a custom extension method that resolves a DbContext via my fixture and seeds data using the given seeder.

[aivascu]

@mrukas I see what you mean. In EntityFrameworkCore.AutoFixture I also solved this problem by clearing the ChangeTracker. You can check this test here.
I was certain I added it to the readme samples. I'll add it on first occasion.

You could try to use the extension method I provided in the previous comments of this thread, but I do not recommend this approach.

[mrukas]

@aivascu Thanks for your help!
I came up with a custom solution that allows me to directly create new instances of already frozen objects.

    public static class FixtureExtensions
    {
        public static TEntity CreateNew<TEntity>(this IFixture fixture) where TEntity : class
        {
            return fixture.Create<UnfrozenValue<TEntity>>().Value;
        }
    }

    public class UnfrozenCustomization : ICustomization
    {
        public void Customize(IFixture fixture)
        {
            fixture.Customizations.Add(new FilteringSpecimenBuilder(
                new UnfrozenValueBuilder(),
                    new ExactTypeSpecification(typeof(UnfrozenValue<>))));
        }
    }

    public class UnfrozenValueBuilder : ISpecimenBuilder
    {
        public object Create(object request, ISpecimenContext context)
        {
            if (request is null || request is not Type t)
            {
                return new NoSpecimen();
            }

            var wrappedType = t.GenericTypeArguments.First();
            var result = new MethodInvoker(new GreedyConstructorQuery()).Create(wrappedType, context);

            if (result is NoSpecimen)
            {
                return new NoSpecimen();
            }

            return Activator.CreateInstance(typeof(UnfrozenValue<>).MakeGenericType(wrappedType), result)!;
        }
    }

I know that it does not really unfreeze the frozen types, but at least it allows me to create new instances of already frozen types and still use the fixture to resolve the other dependencies.

I can now creatye a new context like this, without having to clear the ChangeTracker:

var contextToQuery = fixture.CreateNew<ApplicationDbContext>();