Sharing my experience trying to override class construction/fixture construction

[Notorious-Coding]

Hello !

I struggled a lot with something, i found the solution, but i wanted to share my experience.
I don't know if it's relevant, feel free to ignore if not.

Context:

I'm building an integration test framework that have a integration for every TestFramework, including NUnit, MSTest, XUnit, and, of course, TUnit.

My framework define an Environment (wich is in fact a Fixture, or DataSource, depending on the nomenclature).
An Environment handle the lifecycle of a collection of Infrastructures.
For now, Environment configure a IServiceCollection, build a ServiceProvider, and use it to inject Infrastructure with their dependencies.

Inside Environment, i was using IServiceProvider as a service locator. It works, but i don't like it.
Thats why i wanted to move up the service provider and instantiate my environment with it.

Here's how it work :

• Create a class that implements IDependencyInjectionConfigurator (for example, MyDependencyConfigurator)
• Add [InjectionConfigurator(typeof(MyDependencyConfigurator))] to the test class.
• Then, the Fixture<Environment> class passed or built by the test class (depending on the framework)
  • retrieve the current test class
  • instantiate all configurators found via its attributes.
  • Apply found configurators on IServiceCollection
  • Instantiate the Environment.

For reminder, i need to make an integration of that framework for every test framework, so i try to be as consistant as i can, for maintenance purpose.
That's why every test framework use a Fixture, even if i could do it differently (eg, MSTest could instantiate the environment directly, but i still use the Fixture class).

Every framework are using the same code.
The only thing that differs is the way to find the current test class type.

Here's where i struggled (the solution was easy but i missed it)

in XUnit, i passed (TestContext.Current.TestClass as XunitTestClass)?.Class
in NUnit, i passed GetType(), (since OneTimeSetup is a test class instance method.
in MSTest, i used Type.GetType(testContext.FullyQualifiedTestClassName) inside the static ClassInitialize method (decorated with [ClassInitialize(InheritanceBehavior.BeforeEachDerivedClass)]µ

And, i really struggled to find a way to do that in TUnit.
Here's some code, so you have a bit more context :

    [InjectionConfigurator(typeof(TUnitDependencyInjectionConfigurator))]
    [ClassDataSource(Shared = [SharedType.PerClass])]
    [NotInParallel]
    public abstract class IntegrationTest<T> : NotoriousTest.IntegrationTest<T> where T : EnvironmentBase
    {
        public IntegrationTest(TUnitFixture<T> fixture)
        {
            Fixture = fixture;
        }

        [After(Test)]
        public async ValueTask Reset()
        {
            await Environment.Reset();
        }
    }

My problem was : How TUnitFixture could know wich testclass is currently tested.

Here's all the thing i tried to :

• Use TestContext.Current to retrieve the current class type
  • It was empty in the datasource constructor
• Create a CustomDataSourceAttribute that inherits from DataSourceGeneratorAttribute, and override GenerateDataSources to create my fixture, and use the TestClassInstance props to retrieve the type.
  • Since ClassDataSources.Get is internal, i would lose all the native caching logic of fixtures in TUnit. Even if my framework support (for now), only class sharing, i might extend that to multiple classes (like TestSession, Collection, etc).
• Inherit from ClassDataSource
  • ClassDataSource is sealed
• Create a Custom ClassConstructor
  • By looking to the code, i found that created DataSources were not passed to the ClassConstructor custom, so i couldnt do anything without loosing native caching system as well.
• Use a DependencyInjectionDataSourceAttribute:
  • If i was only supporting TUnit, it would be the go to solution, but i need that "fixture layer", that act like an Adapter.

 private async Task<InstanceCreationResult> CreateInstanceForMethodDataSources(
        TestMetadata metadata, int classDataAttributeIndex, int classDataLoopIndex, object?[] classData, TestBuilderContext testBuilderContext)
    {
        try
        {
            // Try ClassConstructor first - if one is configured, it handles instance creation
            var attributes = testBuilderContext.InitializedAttributes ?? metadata.GetOrCreateAttributes();
            
            // /!\ HERE - classData is not passed, then ClassConstructor could not use it. 
            var instance = await ClassConstructorHelper.TryCreateInstanceWithClassConstructor(
                attributes,
                metadata.TestClassType,
                testBuilderContext,
                metadata.TestSessionId);

            if (instance != null)
            {
                return InstanceCreationResult.CreateSuccess(instance);
            }
            
            // Fall back to InstanceFactory
            // ...
    }
}

THEN, by looking trought the code, i found that TestBuilderContext.Context is available at this moment, and i could use it to get the class type.

(Yes, all of this, just to find out there a static property that do the job, and i find later that it was in the TestContext & Output docs, kinda mad but kinda happy that there is a simple way).

And then, i made my fixture, and everything work just fine :

public class TUnitFixture<TEnvironment> : Fixture<TEnvironment>, IAsyncInitializer, IAsyncDisposable where TEnvironment : EnvironmentBase
{

    public TUnitFixture(): base(TestBuilderContext.Current?.TestMetadata.Class.Type)
    {

    }

    public async Task InitializeAsync() => await Environment.Initialize();
    public async ValueTask DisposeAsync() => await Environment.Destroy();
}

Here's my thoughts about that :

• Why ClassDataSourceAttribute is sealed ?
  • It could be nice to inherit from it and have some behaviour in addition.
• Class constructor could take classData to modify/edit/customize without making change to the "creation" itself
  • ClassConstructor could still create datasource from scratch, but as well take already created ones.
• If ClassDataSourceAttribute should remain sealed, maybe ClassDataSources could be public, and not internal. (TestClassTypeHelper is public btw, and used just before ClassDataSources).

That's it.
I don't know if it's relevant to make improvement to TUnit, maybe all of this is made on purpose and i just don't know why.

Just thought my experience with it could be interesting !
Thanks for your work, have a good day !

[thomhurst]

If you wanna re-use the same logic that ClassDataSourceAttribute uses, this is actually exposed under SharedDataSources. So you can call SharedDataSources.GetOrCreate<T>(...) in your own logic.

ClassConstructor exists for very niche scenarios. Most of the time, you simply just need to pass it test data, and then TUnit handles the rest

[Notorious-Coding]

Okay, thanks !
SharedDataSources could really be helpfull for me, ima take a look !