FluentAssertions 6.12.1 版本中默认接口方法导致的等效性断言问题分析

在 FluentAssertions 6.12.1 版本中，当使用 BeEquivalentTo 方法比较包含默认接口方法(DIM)的接口实现时，会出现断言失败的情况。这个问题在 6.12.0 及之前版本中表现正常，但在 6.12.1 版本中成为了一个回归性问题。

问题现象

当比较两个实现了相同接口的对象列表时，如果接口中包含默认实现的属性或方法，断言会失败并提示"Expectation has property X that the other object does not have"。例如以下测试代码：

public void BeEquivalentTo_Default_Interface_Method()
{
    List<ITest> lista = [new Test { Name = "Test" }];
    List<ITest> listb = [new Test { Name = "Test" }];

    lista.Should().BeEquivalentTo(listb); // 断言失败
}

public class Test : ITest
{
    public string Name { get; set; }
}

public interface ITest
{
    public string Name { get; }
    public int NameLength => Name.Length; // 默认接口方法
}

技术背景分析

这个问题源于 C# 8.0 引入的默认接口方法(DIM)特性与 FluentAssertions 类型成员扫描机制的交互问题。默认接口方法允许在接口中提供方法的默认实现，但这些实现只有在通过接口类型访问时才可见。

在 FluentAssertions 的等效性比较过程中，系统需要扫描对象的成员来进行深度比较。6.12.1 版本对成员扫描机制进行了重构以修复其他问题(#2146)，这导致了对默认接口方法处理的变化。

根本原因

问题的核心在于类型系统视角的差异：

1. 当通过接口类型(ITest)访问对象时，可以看到默认接口方法(NameLength)
2. 当通过具体类型(Test)访问对象时，默认接口方法不可见

在等效性比较过程中，FluentAssertions 需要处理以下复杂情况：

• 编译时类型(ITest)与运行时类型(Test)的差异
• 默认接口方法只在特定上下文中可见
• 显式接口实现带来的额外复杂性

6.12.0 版本的实现较为简单，意外地"支持"了这种情况，而 6.12.1 版本更精确的类型处理反而暴露了这个问题。

解决方案

FluentAssertions 团队在 6.12.2 版本中修复了这个问题。修复方案涉及改进类型成员扫描机制，使其能够正确处理接口默认方法的情况。

对于开发者而言，如果遇到类似问题，可以：

1. 升级到 6.12.2 或更高版本
2. 临时解决方案是显式排除接口默认方法：

lista.Should().BeEquivalentTo(listb, options => options.Excluding(x => x.NameLength));

总结

这个问题展示了现代C#特性与测试框架交互时可能出现的微妙问题。FluentAssertions 团队通过快速响应和发布修复版本，维持了框架的稳定性和可靠性。对于使用默认接口方法的项目，建议保持测试框架的最新版本以获得最佳兼容性。