ClassConstructorAttribute Priority And Inheritance

[Xen0byte]

Hi @thomhurst,

As I was setting up dependency inversion for a test project, I noticed that ClassConstructorAttribute can be used on both assemblies and classes, so I added it to each test class as needed and that worked fine. However, in order to simplify the usage and cut down on the boilerplate code, I thought I would be able to set an assembly attribute with a type that has access to a global service provider while being able to override that with a class attribute of a more specific type which only has access to a local service provider, e.g. [assembly: ClassConstructor<GlobalDependencyResolver>] versus [ClassConstructor<LocalDependencyResolver>]. I realised this doesn't quite work as I expected it to, and I was wondering if you would consider allowing for the class attribute to override the assembly attribute, in order to provide a class with more specific dependencies.

On a different but slightly related topic, I also tried to inherit from ClassConstructorAttribute so that I could "rename" the attribute to something that fits my project a little better, but I wasn't able to do so due to 1) error about overriding the attribute usage, and 2) if I suppress the error or omit the attribute usage the tests fail discovery. Any suggestions on what might be a correct way to "rename" this attribute?

Regards,
Vlad

[thomhurst]

Yeah being able to override on the class level should work. I'll try and take a look tomorrow at that.

As for renaming, you can't really because I use a source generator and so I need static well known types to find and inspect.

You could use a using Alias instead?

using DependencyInjectionAttribute = TUnit.Core.ClassConstructorAttribute<GlobalDependencyResolver>;

[Xen0byte]

Brilliant, many thanks!

[Xen0byte]

Hi @thomhurst, just to add a bit more info to this. I just realised that when you attempt to override the assembly attribute with a class attribute, what ends up happening is that the tests get duplicated, supposably because the test class gets constructed twice in this scenario.

[thomhurst]

Ah yeah that makes sense. It thinks you're registering 2 data sources. Which you very well could be to be fair. I'd need to think of a clean way to "remove" a data source I guess. Might be tricky