Before the big 5.0 breaking change when ShouldBeEquivalentTo still existed I could do the following
var thing = GetMyComparable();
var expected = new MyClassThatImplementsIComparable();
thing.ShouldBeEquivalentTo(expected);
However after 5.0 when attempting to fix this by changing thing.ShouldBeEquivalentTo(expected) to thing.Should().BeEquivalentTo(expected) I notice that this is not possible. Should() is returning an IComparableAssertions object which does not have a BeEquivalentTo method.
I thought about that, but then I wondered why anybody would use Should().BeEquivalent on an IComparable. What do you try to accomplish here?
I have two different classes that "look the same", one is a DTO and another one is a domain object with additional logic. I want to compare that these are equivalent in the sense that for each public property on the DTO there's a corresponding property on the domain object that contains the same data. But I do would highly prefer to not create another domain object to compare with since that is more work than comparing it with the DTO.
Ah, that makes sense indeed. So maybe I can just add BeEquivalentTo to the ComparableAssertions.
@wastaz FYI: 5.1.1 has just been released with the fix.
Thanks again for reporting this.
Most helpful comment
Ah, that makes sense indeed. So maybe I can just add
BeEquivalentToto theComparableAssertions.