Improve inference of type arguments in generic test methods

[michaelamaura]

Currently the deduction of type arguments in NUnit is somewhat limited.

For example the following will work:

public static ITestCaseData[] TestCasesForEqualitiy =
{
    new TestCaseData(1, 1).Returns(true), 
    new TestCaseData(1, 2).Returns(false), 
};

[Test]
[TestCaseSource("TestCasesForEqualitiy")]
public bool Equality<TElement>(TElement left, TElement right)
{
    return left.Equals(right);
}

While the following won't work:

public static ITestCaseData[] TestCasesForEqualitiy =
{
    new TestCaseData(1, 1).Returns(true), 
    new TestCaseData(1, 2).Returns(false), 
};

[Test]
[TestCaseSource("TestCasesForEqualitiy")]
public bool Equality<TElement>(TElement? left, TElement? right)
{
    return left.Equals(right);
}

As far as I can see the modification would be local to NUnit.Framework.Internal.Builders.NUnitTestCaseBuilder.GetTypeArgumentsForMethod(...).

I have coded a somewhat complex type inference logic for another project. I'll check into it and will happily supply it to NUnit project.

[michaelamaura]

I'm starting the adaption in a new branch in my forked version of NUnit framework: issue-150-better-type-inference.

The current type inference also seems to be a bit buggy, assuming NUnit's type inference should work just as the compiler's type inference. Or is it really meant to be "smarter"?

[CharliePoole]

Please clarify which part of NUnit you mean. NUnit does type conversion
for various kinds of attributes that provide parameters to test methods.
The conversion is not centralized by design, but is handled by the
attributes that are used to specify the data.

In general, we expect you to use the types that your methods require. After
all, it's you writing the method and you providing the data. However, in
some special cases and for historical reasons, some attributes will
continue to handle certain special cases. For example, TestCaseAttribute
can only be constructed with arguments that are acceptable to the compiler.
This doesn't include (among others) decimal, so we provide convsion to
decimal.

Because each attribute is potentially different, it will be easier to
comment if you initially limit discussion to a particular attrribute.

Charlie

PS: All of the above refers to the NUnit 3.0 architecture. NUnit 2.x is a
different matter, but since it's dead we need not speak of it further. :-)

On Fri, Jun 27, 2014 at 4:24 PM, Michael Krüske notifications@github.com
wrote:

I'm starting the adaption in a new branch in my forked version of NUnit
framework: issue-150-better-type-inference
https://github.com/michael-krueske/nunit-framework/tree/issue-150-better-type-inference
.

The current type inference also seems to be a bit buggy, assuming NUnit's
type inference should work just as the compiler's type inference. Or is it
really meant to be "smarter"?

—
Reply to this email directly or view it on GitHub
#150 (comment)
.

[CharliePoole]

Let's continue discussion before you get too far in coding. I understand that programmers like to talk in code - I do it myself - but it's nice to know that everyone agrees with what you are trying to do before moving ahead.

Your code does answer one question of mine: "What part of NUnit do you mean?" From what you're working on, I guess it's the part that converts arguments passed to tests to the proper Type to match a generic parameter. You're focusing on the overall conversion logic in NUnitTestCaseBuilder, which handles conversions from data that comes from any source.

This could be an issue, if different rules need to apply to different attributes (as they now do) but not necessarily. That is, NUnitTestCaseBuilder could handle the conversions we always want to occur while the attributes themselves take care of specific conversions - as TestCaseAttribute does when converting strings to various Types.

I'm not sure I agree with your statement that NUnit should do exactly what the compiler (C#?) does. Our approach up to now has been to work with the conversions that .NET does when invoking methods with arguments, only doing additional conversion where it's absolutely necessary.

Anyway, while we can have this discussion when you reach the point of a merge request, it may save you some effort if we do it now.