C#单元测试使用指南与最佳实践全面解析

C#单元测试：那些看似“通过”却暗藏玄机的陷阱

在C#单元测试的世界里，一个绿色的“通过”标识有时并不代表万事大吉。恰恰相反，它可能掩盖了逻辑深处的隐患。今天，我们就来聊聊几个最常见的、容易让人掉以轻心的陷阱，帮你把测试写得既严谨又可靠。

Assert.AreEqual对引用类型默认比较引用地址而非内容，因多数类未重写Equals；值类型安全；引用类型应优先用Assert.IsTrue(obj1.Equals(obj2))并确保重写Equals和GetHashCode。

为什么 Assert.AreEqual 有时不报错但逻辑不对

这个问题堪称经典。你以为Assert.AreEqual在帮你比较两个对象的内容是否一致？其实不然。对于引用类型，它默认调用的是Equals方法，而绝大多数自定义类压根就没重写这个方法。结果就是，它比较的其实是两个对象在内存中的地址，而非你关心的字段值。试想一下，两个新构造的Person对象，所有字段都一模一样，AreEqual却依然返回false，是不是很让人困惑？

• 值类型（int、DateTime、struct）：可以放心使用，因为它们直接比较值。
• 引用类型：优先使用Assert.IsTrue(obj1.Equals(obj2))，但前提是，你必须确保类已经正确重写了Equals和配套的GetHashCode方法。
• 快速验证对象结构：如果只是想快速验证两个对象序列化后的结构是否一致，可以改用Newtonsoft.Json.JsonConvert.SerializeObject将对象转为字符串再比较。当然，这个方法只适用于没有循环引用、没有动态字段的简单场景。
• 集合比较：千万别直接用AreEqual来比较集合！正确的姿势是使用CollectionAssert.AreEqual（顺序敏感）或CollectionAssert.AreEquivalent（忽略顺序）。

如何让 [TestMethod] 正确识别异步方法

异步编程大行其道，测试方法自然也得跟上。但如果你图省事，直接写成async void TestMethod()，那麻烦就来了。测试框架无法等待这个异步方法完成，常常表现为“测试通过”的假象，但实际上断言可能根本没执行，或者干脆抛出一个莫名其妙的InvalidCastException（尤其是在MSTest v2中，它明确不支持async void）。

• 必须返回 Task：正确声明应该是public async Task MyTest()。
• 避免死锁：在测试方法内部，切忌使用.Wait()或.Result来阻塞等待，特别是在UI或ASP.NET这类带有同步上下文的场景里，极易引发死锁。
• 测试异步异常：想验证异步方法是否抛出了特定异常？请使用await Assert.ThrowsExceptionAsync(async () => await target.Method())。
• 框架差异：MSTest、xUnit、NUnit都支持返回Task的测试方法。不过有个小细节：xUnit要求方法名不能包含Async后缀（命名随意），而MSTest则没有这个限制。

[DataRow] 和 [DynamicData] 怎么选才不掉坑

数据驱动测试能极大提升覆盖率，但选错数据源属性，也可能让你掉进坑里。[DataRow]简单直接，参数在编译期就确定了；[DynamicData]则灵活得多，可以在运行时动态生成数据，但复杂度也随之而来。

• [DataRow]：适合小规模、输入稳定的场景，比如测试边界值（0, -1, int.MaxValue）。需要注意的是，其参数类型必须和方法签名严格匹配，否则编译直接失败。
• [DynamicData]：提供该数据的方法必须是static的，并且返回IEnumerable。这里有个隐蔽的坑：如果方法返回null或执行yield break，测试会直接跳过且不报错，很容易导致漏测。
• 外部文件数据源：如果想从JSON或CSV文件读取动态数据，务必注意测试运行时的当前工作目录。默认情况下，它通常是bin\Debug\net6.0\这类输出目录，而非你的项目根目录。建议使用Path.Combine(AppContext.BaseDirectory, “data.json”)来构建绝对路径。
• 性能提醒：避免在[DynamicData]方法里执行耗时操作（比如发起HTTP请求），因为它会在测试发现阶段就被调用，从而拖慢整个测试集的加载速度。