Fluent Assertions Should().Should().BeEquivalentTo 忽略排除的成员

Posted 2023-03-24

【中文标题】Fluent Assertions Should().Should().BeEquivalentTo 忽略排除的成员

【英文标题】：Fluent Assertions Should().Should().BeEquivalentTo ignores excluded member

【发布时间】：2019-05-01 13:09:03

【问题描述】：

我在集成测试中创建两个相同类型的对象，但试图排除在创建对象时生成的自动增量成员。

我成功排除了 RecordId 和 Number 属性，但对 Id 属性的等效性测试失败。 RecordId 和 number 属性继承自抽象类，但 Id 不同之处在于它是继承自抽象类的抽象属性，然后被覆盖。

Id 属性是一个抽象字符串属性并且是只读的。

//CreateJob creates indentical jobs, but with autoincremented id, number and recordid   
Job job1 = CreateJob();
Job job2 = CreateJob();

job1.Should().BeEquivalentTo(job2, config => config
   .Excluding(o => o.RecordId)
   .Excluding(o => o.Id)
   .Excluding(o => o.Number)
);

消息：预期的成员 ID 为“45”，但“46”与“6”不同 （索引 1）。

配置： - 使用声明的类型和成员

按值比较枚举 排除成员 root.RecordId 排除成员 root.Id 排除成员 root.Number 按名称匹配成员（或抛出） 没有自动转换。 严格控制字节数组中的项目顺序

我也尝试使用 WithTracing() 选项运行，但它没有提供有关相关属性的信息。

我已阅读文档，但没有找到任何表明排除抽象或虚拟属性是不可能的，我错了吗？

我在 5.5.0 和 5.5.3 版本上试过这个，结果相同。

编辑：

我已经检查并再次检查了该类或其继承的类都不等于。

【问题讨论】：

Job 是否覆盖 Equals？

不，job 和其中的任何类都不是从 override Equals 继承的。这是定义 Id 和 Job 最终继承自的基类：我们在其上使用了 ElasticSearch 属性，这会不会弄乱它？公共抽象类 IndexObject [NoCaseKeywordString] 公共虚拟字符串 Id 获取；

其实IndexObject类的属性应该是抽象的而不是虚拟的。

你能发一个minimal reproducible example吗？

事实上，我建议将其发布到github.com/fluentassertions/fluentassertions/issues，以便我们进一步调查。

【参考方案1】：

我看到了，我的对象覆盖了 Equals(object obj)，但我没想到 BeEquivalentTo 函数会受到影响。

我认为BeEquivalentTo 会改为通过对象图？