Asger Hallas
Asger Hallas
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.
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...
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.
I have worked around it using custom comparisons like this one: https://github.com/asgerhallas/ShouldBeLike/blob/master/ShouldBeLike/CyclesComparison.cs
Note: Above comparison is not thread safe and should not be reused between comparisons. Make a new instance for every call to ShouldDeepEqual(). I have also made a thread safe...
+1 for this "For any exception destructurer, arguably, the core IDestructuringPolicys should take precedence for non-exception values within the exception tree. If ReflectionBasedDestructurer adhered to this, it would work fine...
Hi, any news on this? :)
I suspect it is this addition that makes the difference: https://github.com/jamesfoster/DeepEqual/blob/dbec89dae6bfeea89abb1422e57fa17cac987fdb/src/DeepEqual/ComplexObjectComparer.cs#L33
Allow me to bump this question :) Is it intentional that two classes of different types, but both with no properties, should return a Pass? I'd say it would be...