"Test instance is null for test after instance creation" for test class with empty data source

[TheRumle]

I am using version 0.53.0. I have a class injecting a collection of data that is filtered and used as input for inherited tests.

[InheritsTests]
public sealed class BugRecreationTest() : BugRecreationTestAbstract([1, 2, 3, 4, 5, 6, /*7*/ 8, 9]);

public abstract class BugRecreationTestAbstract(IEnumerable<int> data)
{
    public readonly IEnumerable<int> Seven = data.Where(d => d == 7);
    public readonly IEnumerable<int> Odd = data.Where(d => d % 2 == 1);
    public readonly IEnumerable<int> Even = data.Where(d => d % 2 == 0);

    [Test]
    [InstanceMethodDataSource(nameof(Even))]
    public async Task EvenIsEven(int d) => await Assert.That(d).IsEven();

    [Test]
    [InstanceMethodDataSource(nameof(Seven))]
    public async Task SevenIsSeven(int d) => await Assert.That(d).IsEqualTo(7);
    
    [Test]
    [InstanceMethodDataSource(nameof(Odd))]
    public async Task OddIsOdd(int d) => await Assert.That(d).IsOdd();
}

Here, even after rebuilding, deleting build and obj directories, etc. I get failing tests with Test instance is null for test OddIsOdd after instance creation. ClassInstance type: null at TUnit.Engine.Services.SingleTestExecutor.ExecuteTestInternalAsync(AbstractExecutableTest test, CancellationToken cancellationToken)l

I have other test where this issue also occurs, but where Odd would run, but Seven and Even would not. Perhaps that is only due to the order of execution for some reason.

[TheRumle]

The issue is likely connected to the fact that the bug implementation uses readonly fields and not methods.
Changing the fields to

• Properties: Still breaks test
• Methods: Tests works, and the empty test is just not run at all. This is what I expected to happen

One solution could be to implement a dedicated PropertyMethodDataSource or something similar or give a compiletime error when using fields/properties instead of methods @thomhurst.

[thomhurst]

I might just extend MethodDataSource to work with properties. Should be fairly simple. (And properties are technically syntactic sugar for methods anyway!)

[TheRumle]

@thomhurst I believe that is the correct approach. My question is then, is the name for `MethodDataSource accurate or would it confuse API consumers? I would find myself looking for PropertyDataSource after seeing MethodDataSource. And what about fields? Would it maybe make sense to have a more descriptive name and then encompass all three through the same API?

[thomhurst]

I probably wouldn't do fields. I don't see any need since having a property is just as easy.

I could do property data source too. I just like the idea of it being behind a single attribute. But a name that encompasses both doesn't really exist apart from "Member". But I think member is vague and unclear if you're not used to working with reflection etc.

[TheRumle]

I could do property data source too. I just like the idea of it being behind a single attribute. But a name that encompasses both doesn't really exist apart from "Member". But I think member is vague and unclear if you're not used to working with reflection etc.

I wholeheartedly agree. Member is too broad and vague, as I would expect it to work for fields too... it would sort break 'path of least surprise' when it does not work for all members... although this could maybe be circumvented with an analyzer reporting an "The attribute can only target Properties and Methods" kinda error.