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请求），因为它会在测试发现阶段就被调用，从而拖慢整个测试集的加载速度。
为什么 Moq 的 Setup 没生效
Mock对象是隔离测试的利器，但当你兴冲冲地Setup了一个方法，运行时却发现它根本没被调用，或者返回的不是你预设的值，那种感觉实在糟糕。常见原因无外乎那么几个。
- 方法可 mock 性：如果要 mock 一个类中的方法，该方法必须是
virtual（或protected virtual）的。static、sealed、private方法都无法被 Moq 袋里。接口方法则天然具备可 mock 性。 - 注意属性与委托：对于接口中返回
Func这类委托的属性，你需要 setup 的是它的 getter，而不是尝试去 new 一个 Mock。 - 参数匹配规则：使用
It.IsAny这类参数匹配器时，必须注意一致性。如果方法有多个参数，你不能混用具体值和匹配器（比如一个参数用() “test”，另一个用It.IsAny），这会导致 setup 无法命中。() - 验证调用：想验证某个方法是否被调用了？推荐使用
mock.Verify(x => x.Sa ve(It.IsAny这种明确的方式。尽量避免使用已过时的()), Times.Once) mock.VerifyAll()，它的行为有时难以预料。
说到底，测试里最棘手的往往不是编写断言本身，而是弄清楚“代码到底在哪一步偏离了预期”。是异步操作没等完？是 mock 的方法根本没被调用？还是数据源路径在 CI 服务器上根本不存在？在这些地方，如果不打日志、不单步调试，仅仅依赖那个绿色的对勾，只会让你在错误的道路上越走越远。
