BeOneOf for object comparisons with custom comparer support

[xmarshal]

Background and motivation

Support for custom comparer to compare objects

API Proposal

public class ObjectAssertions<TSubject, TAssertions> : ReferenceTypeAssertions<TSubject, TAssertions>
    where TAssertions : ObjectAssertions<TSubject, TAssertions>
{
    public AndConstraint<TAssertions> BeOneOf<TExpectation>(IEnumerable<TExpectation> validValues, IEqualityComparer<TExpectation> comparer, string because = "", params object[] becauseArgs);
}

API Usage

var obj = new SomeClass(1);
var expected = new[] { new SomeClass(1), new SomeClass(2), new SomeClass(3) };
obj .Should().BeOneOf(expected, new SomeClassEqualityComparer ());

internal class SomeClass
{
    public SomeClass(int key)
    {
        Key = key;
    }

    public int Key { get; }

    public override string ToString()
    {
        return $"SomeClass({Key})";
    }
}

internal class SomeClassEqualityComparer : IEqualityComparer<SomeClass>
{
    public bool Equals(SomeClass x, SomeClass y)
    {
        if (ReferenceEquals(x, y))
        {
            return true;
        }

        if (ReferenceEquals(x, null))
        {
            return false;
        }

        if (ReferenceEquals(y, null))
        {
            return false;
        }

        if (x.GetType() != y.GetType())
        {
            return false;
        }

        return x.Key == y.Key;
    }

    public int GetHashCode(SomeClass obj)
    {
        return obj.Key;
    }
}

Alternative Designs

No response

Risks

No response

[dennisdoomen]

If we add this to BeOneOf, we must also add this to Be and NotBe for consistency. Assuming @jnyrup agrees, are you willing to include that in your PR @xmarshal ?

[jnyrup]

In the proposed signature validValues can have a different type TExpectation than the subject TSubject.

    public AndConstraint<TAssertions> BeOneOf<TExpectation>(IEnumerable<TExpectation> validValues, IEqualityComparer<TExpectation> comparer, string because = "", params object[] becauseArgs);

With the example usage you provide, re-using TSubject for validValues should suffice.

    public AndConstraint<TAssertions> BeOneOf(IEnumerable<TSubject> validValues, IEqualityComparer<TSubject> comparer, string because = "", params object[] becauseArgs);

Also only BeEquivalentTo in ObjectAssertions currently uses TExpectation.
Can you clarify if this is unintentional or why we should add TExpectation.

For even more consistency, we should also add this to BeOneOf and [Not]Be for ComparableTypeAssertions.

For discoverability, this topic is related to #699.

[xmarshal]

In the proposed signature validValues can have a different type TExpectation than the subject TSubject.

Mostly obj.Should() extension method returns non-generic ObjectAssertions
So TSubject will be object
May be we should add ObjectAssertions<TSubject> : ObjectAssertions<TSubject, ObjectAssertions<TSubject>> instead of ObjectAssertions : ObjectAssertions<object, ObjectAssertions> and then TSubject can be used for IEnumerable<TSubject> validValues

[xmarshal]

If we add this to BeOneOf, we must also add this to Be and NotBe for consistency. Assuming @jnyrup agrees, are you willing to include that in your PR @xmarshal ?

I will add when we reach an agreement for API

[dennisdoomen]

May be we should add ObjectAssertions : ObjectAssertions<TSubject, ObjectAssertions> instead of ObjectAssertions : ObjectAssertions<object, ObjectAssertions> and then TSubject can be used for IEnumerable validValues

That would require a Should<T> as well. But due to the way overload resolution works, it will overrule every other Should extension method.

[xmarshal]

That would require a Should<T> as well. But due to the way overload resolution works, it will overrule every other Should extension method.

For even more consistency, we should also add this to BeOneOf and [Not]Be for ComparableTypeAssertions.

So what I should do next?

[dennisdoomen]

Nothing. I'm waiting for @jnyrup's opinion.

[jnyrup]

An alternative API

public class ObjectAssertions : ObjectAssertions<object, ObjectAssertions>
{
    public AndConstraint<ObjectAssertions> BeOneOf<TExpectation>(IEnumerable<TExpectation> validValues, IEqualityComparer<TExpectation> comparer, string because = "", params object[] becauseArgs);
}

public class ObjectAssertions<TSubject, TAssertions> : ReferenceTypeAssertions<TSubject, TAssertions>
    where TAssertions : ObjectAssertions<TSubject, TAssertions>
{
    public AndConstraint<TAssertions> BeOneOf(IEnumerable<TSubject> validValues, IEqualityComparer<TSubject> comparer, string because = "", params object[] becauseArgs);
}

The difference comes for classes deriving from ObjectAssertions<TSubject, TAssertions> e.g. HttpResponseMessageAssertions.
The proposed API would allow HttpResponseMessageAssertions.BeOneOf() to take input of arbitrary types, while it currently only allows input of HttpResponseMessage.

[xmarshal]

alternative API added
should I add Be and NotBe and what signature You suggest?

[dennisdoomen]

An alternative API

Looks good to me.

[xmarshal]

Be and NotBe with comparer added

[jnyrup]

The "alternative API" together with Be and NotBe is approved 👍

[xmarshal]

ok will add test soon

[Corniel]

If TSubject imlements IEquatable<TSubject> I would hope that providing IEqualityComparer<TSubject> is optional?

[jnyrup]

If TSubject imlements IEquatable<TSubject> I would hope that providing IEqualityComparer<TSubject> is optional?

If not providing an IEqualityComparer, wouldn't the existing BeOneOf suffice?
See this example: https://dotnetfiddle.net/N2Rpt6