FluentAssertions：ShouldBeEquivalentTo 方法仍然调用 Object.Equals()？答案

【问题标题】：FluentAssertions: ShouldBeEquivalentTo method still invokes Object.Equals()?FluentAssertions：ShouldBeEquivalentTo 方法仍然调用 Object.Equals()？
【发布时间】：2012-12-23 16:02:14
【问题描述】：

我有一个类，我们称之为Foo，它是一个值类型，因此会覆盖Equals/GetHashCode() 方法。在一个单独的测试夹具中，我想断言 Foo 上的所有属性都已正确设置，而不仅仅是用于相等的属性。出于这个原因，我的测试断言专门使用了ShouldBeEquivalentTo 方法，如果“两个对象图具有相同名称的具有相同值的属性，而与这些对象的类型无关”，文档建议该方法将认为两个对象是等价的。 /p>

但是，ShouldBeEquivalentTo 似乎调用了Foo.Equals 方法，得到了一个真实的结果，然后继续短路ShouldBeEquivalentTo 承诺的基于反射的属性匹配。

这是预期的行为吗？如果是这样，在检查 FA 源时，我发现没有简单的方法可以改变这种行为（IEquivalencyStep 被声明为内部的）。有没有其他方法可以解决这个问题？

编辑：丹尼斯：是的，我比较的两个对象是同一类型的。总而言之，我在 Foo 类上覆盖了 Equals，但不希望 FA 在我的单元测试中使用这种平等概念。

【问题讨论】：

我不完全明白你想要做什么。该对象与您调用 ShouldBeEquivalentTo() 的对象相似吗？
为了将来参考，Dennis 在这里解决了这个问题：fluentassertions.codeplex.com/discussions/428950，说行为在 2.1 中有所改变
Argaz，如果你把你的评论变成答案，我会接受的。

标签： c# unit-testing fluent-assertions

【解决方案1】：

我认为你不能改变这个函数的行为，它假设如果你覆盖Equals - 你希望比较是相同的方式。您可以尝试以下功能：

dto.ShouldHave().SharedProperties().EqualTo(foo);

或者您可以在 Foo 类中实现 NativeEquals 方法，该方法将调用 base.Equals() ，然后显式使用此方法进行比较，它将非常适合值类型。

【讨论】：

不起作用，因为 SharedProperties() 内部使用与 ShouldBeEquivalentTo() 相同的引擎。我知道，因为我设计了它......