NSubstitute中对象相等性验证的陷阱与解决方案

在使用NSubstitute进行单元测试时，经常会遇到对象相等性验证的问题。本文将通过一个典型案例，深入分析为什么看似相同的对象会被NSubstitute判定为不匹配，以及如何正确地进行对象验证。

问题现象

开发者在测试中遇到了一个令人困惑的情况：NSubstitute抛出了ReceivedCallsException异常，提示期望的调用与实际调用不匹配。然而从异常信息来看，两个对象的JSON表示完全一致：

Expected to receive exactly 1 call matching:
    AddAsync({"id":0,"transactionKind":8,"userId":"1",...})
Actually received no matching calls.
Received 1 non-matching call:
    AddAsync(*{"id":0,"transactionKind":8,"userId":"1",...}*)

根本原因

这个问题实际上与.NET的对象相等性比较机制有关，而非NSubstitute本身的缺陷。在.NET中，默认情况下：

1. 对于引用类型，Equals方法执行的是引用相等性比较
2. 除非类显式重写了Equals方法或实现了IEquatable接口
3. 两个不同实例即使所有属性值相同，默认也会被视为不相等

解决方案

1. 使用属性断言（推荐）

最可靠的方式是逐个验证关键属性：

myService.Received(1).AddAsync(Arg.Is<Transaction>(t => 
    t.Amount == -10 && 
    t.UserId == "1" &&
    // 其他重要属性验证
));

这种方法：

• 明确指定了需要验证的属性
• 避免了对象相等性实现的复杂性
• 测试意图更加清晰

2. 实现IEquatable

如果经常需要比较Transaction对象，可以实现IEquatable接口：

public class Transaction : IEquatable<Transaction>
{
    public bool Equals(Transaction other)
    {
        return Amount == other.Amount &&
               UserId == other.UserId &&
               // 其他属性比较
    }
}

3. 使用记录类型(record)

C# 9.0引入的record类型自动实现了值相等性：

public record Transaction
{
    // 属性定义
}

4. 结合FluentAssertions

可以使用BeEquivalentTo进行深度比较：

myService.Received(1).AddAsync(Arg.Is<Transaction>(t => 
    t.Should().BeEquivalentTo(expectedTransaction)
));

最佳实践建议

1. 在测试中，优先考虑属性断言而非完整对象比较
2. 对于值对象，考虑实现IEquatable或使用record类型
3. 避免依赖默认的对象相等性比较
4. 在复杂对象比较时，明确指定需要验证的关键属性

理解这些概念后，开发者就能更有效地使用NSubstitute进行对象验证，避免类似的相等性比较陷阱。