MSTest单元测试如何仅在断言失败时生成错误消息实现提速

原生框架支持情况 #

Microsoft.VisualStudio.TestTools.UnitTesting 原生没有提供直接接收Func<string>委托实现延迟消息的断言重载。你提到的Assert.AreEqual(expected, actual, message, params object[] parameters)格式化重载，会在断言方法执行时立刻对所有入参求值，哪怕断言最终通过，也会提前完成字符串拼接、参数计算，无法解决无效性能消耗的问题。

最小成本实现方案 #

不需要重写Assert类的所有原生逻辑（比如double类型的delta容差判断、集合比较规则等内置能力），可以利用MSTest断言消息参数的隐式特性实现：当传入的消息参数实现了IFormattable接口时，框架仅会在断言失败、需要输出错误文本时，才调用该对象的格式化方法生成最终消息，断言通过时不会触发任何消息生成逻辑。

你只需要实现一个极轻量的延迟消息包装类即可，无需引入第三方依赖：

public class LazyAssertMessage : IFormattable
{
    private readonly Func<string> _messageBuilder;

    public LazyAssertMessage(Func<string> messageBuilder)
    {
        _messageBuilder = messageBuilder ?? throw new ArgumentNullException(nameof(messageBuilder));
    }

    public string ToString(string? format, IFormatProvider? formatProvider) => _messageBuilder();
    public override string ToString() => _messageBuilder();
}

使用方式 #

所有原有断言调用无需修改方法本身，只需要将原来直接传入的消息生成逻辑，包裹在LazyAssertMessage实例中即可，完全兼容所有原生Assert重载：

// 原有高耗写法：无论断言是否通过，都会立刻执行getDetailedErrorContext生成消息
Assert.AreEqual(expected, actual, message: getDetailedErrorContext(expected, actual));

// 延迟消息写法：断言通过时，lambda永远不会执行，无额外性能开销
Assert.AreEqual(expected, actual, new LazyAssertMessage(() => getDetailedErrorContext(expected, actual)));

针对你提到的列表拼接类复杂消息场景，改造方式完全一致：

Assert.AreEqual(expected.Count, actual.Count, new LazyAssertMessage(() => 
    "All the items in the list are: " +
    string.Join(", ", actual.Select(o => $"[{o.Id}: {o.Description}]"))
));

方案优势 #

• 100%保留MSTest原生断言的所有内置逻辑，不需要重复实现数值容差、类型比较、空值判断等框架已有的能力
• 重构成本极低：仅需要包裹原有消息生成代码，不需要调整断言方法、判断逻辑
• 性能收益完全符合预期：断言通过时不会执行任何消息生成相关的代码，彻底解决无效的性能损耗

内容的提问来源于stack exchange，提问作者Alain