[Feature]: Covariant assertions

[ascott18]

Problem Statement

It would be nice if source generated assertions (or all assertions?) could be made to be covariant. Right now, an assertion for a base type cannot be used against a derived type because TValue is invariant in IAssertionSource<TValue>.

This somewhat relates to #4825

Proposed Solution

I would like the following assertion to work seamlessly without having to manually cast Impl to IInterface:

public class UnitTest1
{
    [Test]
    public async Task TestWithMemberData()
    {
        Impl item = new Impl { Foo = "bar" };
        await Assert.That(item).HasFoo("bar");
    }
}

public interface IInterface { public string? Foo { get; set; } }

public class Impl : IInterface { public string? Foo { get; set; } }

public static partial class Assertions
{
    [EditorBrowsable(EditorBrowsableState.Never)]
    [GenerateAssertion(ExpectationMessage = "to have foo '{expected}'")]
    public static bool HasFoo(this IInterface target, string expected)
    {
        return target.Foo == expected;
    }
}

Alternatives Considered

No response

Feature Category

Assertions

How important is this feature to you?

Nice to have - would improve my experience

Additional Context

No response

Contribution

• I'm willing to submit a pull request for this feature

[thomhurst]

I did try this before but I wasn't able to get it to work

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ascott18]

I would still be interested in this. I think the generic constraint solution that Copilot produced is actually reasonably elegant without requiring sweeping, complicated breaking changes across the codebase, even if it doesn't use a true covariant interface as the extension method target.

I played around with a "true covariance" solution here main...ascott18:TUnit:ascott/pseudo-covariance (don't mind the contradictory branch name), but it just seems a bit messy and hacky and ultimately still requires mapping the assertion context just like was done in #4831. It results in a more complex experience if manually authoring assertions due to the smattering of new interfaces and base classes.

On the other hand, the generic constraint approach in the source generators #4831 results in an unchanged API surface - it just expands the generated assertions to be more capable, which is ultimately all most people would want here anyway.