Comparing object to primitive values is unexpected always deep equal.

[tugend]

Given the example below, I would never expect the object Foo carrying the value 12 to equal 42. It seems like a bug to me, and I'm afraid it'll result in many unexpected false positives.

        [Fact]
        public void ShouldFail()
        {
            new Foo(12).ShouldDeepEqual(42);
        }

        public class Foo
        {
            public int Value { get; }

            public Foo(int value)
            {
                this.Value = value;
            }
        }

[jamesfoster]

This is definitely a major bug. If I get time this weekend I’ll look into it.

[tugend]

Hi @jamesfoster , Have you been able to verify the bug, any status on the issue?

[asgerhallas]

I can confirm this. It's because the comparison returns ComparisonResult.Inconclusive, and ShouldDeepEqual only fails on ComparisonResult.Fail. I've been caught by the same in other situations.

[asgerhallas]

Is there a reason inconclusive results that bubbles all the way to the top of the comparison doesn't throw?

I made a wrapper like ShouldDeepEqual, that did just that, but then discovered the same thing goes for comparing to object instances, just the other way around:

    [Fact]
    public void ObjectsAreEqual()
    {
        var comparison = new ComparisonBuilder().Create();
        var (result, context) = comparison.Compare(new ComparisonContext(), new object(), new object());
        Assert.Equal(ComparisonResult.Pass, result); // Fails, as it is inconclusive
    }

Isn't this a sign of a missing comparer (either internal or custom)?

[asgerhallas]

These issues can be worked around though with custom comparers. https://github.com/asgerhallas/shouldbelike tries to deal with this issue, cycles, JTokens and tuples.

[jamesfoster]

Fixed in 4.0.0