TestCase- and TestCaseSourceAttribute cannot handle generic test methods where method parameter is Nullable<T>

[wimvangool]

When using the TestCaseAttribute or TestCaseSourceAttribute on a test-method, the test-method is allowed to be generic, as long as the testcase-arguments provided for each testcase can be used by NUnit to resolve all the open generic type parameters of the test-method to generate and run a new test.

However, NUnit fails to resolve the generic type parameter TValue when that parameter is constrained to be a struct and the actual method parameter is declared as a Nullable and the provided testcase-arguments are either of type TValue or Nullable. For example, given the following test-method, NUnit will fail to run the method with the message 'Unable to determine type arguments for method':

[TestCase(0)]
public void SomeTest<TValue>(TValue? value) where TValue : struct
{
    ...
}

The expected behavior is, of course, that NUnit will be able to resolve the desired type of TValue to Int32 and then pass the test-case argument (0) as a value for the method parameter.

This bug was discovered using NUnit 4.1.0 but is still present in NUnit 4.2.2.

[manfred-brands]

@wimvangool Than you for your report. I can confirm your observations.
There are two workaround:

• [TestCase(0, TypeArgs = [typeof(int)])]
• [TestCase<int>(0)]

[manfred-brands]

Note that is not possible to resolve the type if null is passed in.
Even in a TestCaseSource when converting a default(Nullable<T>), which is a struct into object it becomes null.
Note that this is not limited to struct, TestCase also doesn't support null for Generics classes.
That is because NUnit converts all values to object and we cannot call GetType() on null.

One option would be to resolve all null values to use object or Nullable<int>, but I don't think that is the correct approach.

@wimvangool Can you elaborate more on your actual test why you expect nullables?

[wimvangool]

@manfred-brands Thanks for confirming the issue and the suggested workarounds. Would these workarounds also work for the TestCaseSourceAttribute?

The reason I ran into this issue in the first place is because I am currently developing a library for validating arguments and/or message-properties and so there are a lot of test-methods to verify that the framework behaves as expected when comparing a certain value with one or more comparands. In some overloads, the value and the comparand are nullable values, and so my test-methods also accept nullable values for these parameters, e.g.:

[TestCaseSource(nameof(TestCases_Where_LeftIsEqualToRight), [EquatableValueType])]
public void NullableValue_IsEqualTo_ReturnsArgument_If_ArgumentIsNotNull_And_ArgumentIsEqualToOtherValue<TValue>(TValue? value, TValue? other) where TValue : struct, IEquatable<TValue>
{
    var argument = Ensure.ThatNullable(value).IsEqualTo(other);

    Assert.That(argument.Value, Is.EqualTo(value));
}

In the test-method above, the ThatNullable<TValue>(TValue? value) expects a Nullable<TValue> and so I automatically declared both parameters as nullable too. I realize that passing null for both parameters in this case would be a valid reason for NUnit to stuggle resolving TValue, which is why every testcase provided by the TestCaseSourceAttribute here will always provide at least one non-null parameter-value for the test. The case where both are null is tested separately (also because it is a separate testcase altogether).

Given that at least one of the specified parameters is not null I expected NUnit to be able to resolve for TValue. Fortunately, because in this case the first parameter is never null, I can work around this problem by marking the first parameter as non-nullable, and than just specify the type-parameter for the ThatNullable<TValue>(TValue? value)-method explicitly:

[TestCaseSource(nameof(TestCases_Where_LeftIsEqualToRight), [EquatableValueType])]
public void NullableValue_IsEqualTo_ReturnsArgument_If_ArgumentIsNotNull_And_ArgumentIsEqualToOtherValue<TValue>(TValue value, TValue? other) where TValue : struct, IEquatable<TValue>
{
    var argument = Ensure.ThatNullable<TValue>(value).IsEqualTo(other);

    Assert.That(argument.Value, Is.EqualTo(value));
}

Also note that because of the amount of test-cases that require similar test-cases, I am heavily depending on the TestCaseSourceAttribute instead of specifying each test-case with explicit TestCaseAttributes for each test-method. Moreover, the TestCaseSource used here may provide many different types of values (Int32, Guid, etc) as a means to spread out the test-coverage somewhat and so hinting at a specific type to expect defeates the purpose of using a generic parameter altogether for me (that would be similar to just resorting to using explicitly typed parameters for the test-method). The filtered approach might work if you accept to use multiple TestCaseSourceAttributes where each instance is used for specific test values, e.g.:

[TestCaseSource<int>(nameof(TestCases_Where_LeftIsEqualToRight), [EquatableValueType])]
[TestCaseSource<Guid>(nameof(TestCases_Where_LeftIsEqualToRight), [EquatableValueType])]
public void NullableValue_IsEqualTo_ReturnsArgument_If_ArgumentIsNotNull_And_ArgumentIsEqualToOtherValue<TValue>(TValue? value, TValue? other) where TValue : struct, IEquatable<TValue>
{
    var argument = Ensure.ThatNullable(value).IsEqualTo(other);

    Assert.That(argument.Value, Is.EqualTo(value));
}

However, in that case, the explicitly defined type parameter should not only be used to resolve for TValue but also to actively filter the set of test-cases to ensure the values for value and other are always of the correct type.

Long story short, I already have an acceptible work-around for now, but it resolving this issue in the NUnit framework would be nice to have so that my test-code becomes just a tat cleaner. And being able to use a generic type parameter of the TestCaseSourceAttribute to not only resolve for a otherwise unresolvable generic type parameter but also works to filter the testcase parameter values would be a great feature to have.

[manfred-brands]

Would these workarounds also work for the TestCaseSourceAttribute?

Only if the referenced property/method returns TestCaseData which has the TypeArgs property and a generic version:
This allows:

private static IEnumerable<TestCaseData> GenericDataWithGenericConstraint2()
{
    yield return new TestCaseData(2, 2.0) { TypeArgs = [typeof(int), typeof(double)] };
    yield return new TestCaseData(2.0, 2) { TypeArgs = [typeof(double), typeof(int)] };
}

or if targeting net6.0 or greater:

private static IEnumerable<TestCaseData> GenericDataWithGenericConstraint2)
{
    yield return new TestCaseData<int, double>(2, 2.0);
    yield return new TestCaseData<double, int>(2.0, 2);
}