assert断言仅在debug模式生效，release下被移除；assert.istrue无上下文信息，assert.areequal自动显示期望值与实际值；assert.throwsexception需传委托而非直接调用；勿混用debug.assert与测试框架assert。
Assert 断言不是运行时校验工具，它只在 Debug 模式下生效，Release 下默认被移除——如果你指望它在生产环境拦住错误，那会出事。
Assert.IsTrue 和 Assert.AreEqual 的实际差异
很多人以为 Assert.IsTrue 就是“判断为 true”，但它的本质是：检查布尔表达式是否为 true，且不提供上下文信息；而 Assert.AreEqual 在失败时会输出期望值和实际值，对调试更友好。
- 用
Assert.IsTrue(actual > 0)失败时只报 “Assert.IsTrue failed”，你得自己加message参数才能知道actual是多少 - 用
Assert.AreEqual(expected, actual)失败时自动显示类似 “Expected: 42, Actual: -1” 的提示 - 对浮点数比较，必须用
Assert.AreEqual(double expected, double actual, double delta)，否则因精度问题几乎必挂
Assert.ThrowsException 捕获异常的坑
这个方法看似简单，但容易写错成调用后立即执行，导致异常没被框架捕获——它要求传入一个 Action 或 Func 委托，而不是直接调用方法。
- ❌ 错误写法：
Assert.ThrowsException<argumentnullexception>(SomeMethod())</argumentnullexception>—— 这里SomeMethod()立即执行，异常抛到外层，断言根本没机会介入 - ✅ 正确写法：
Assert.ThrowsException<argumentnullexception>(() => SomeMethod())</argumentnullexception> - 如果被测方法带参数，记得闭包捕获正确变量，避免测试用例间污染（比如循环中用
i但没及时捕获）
Debug.Assert 和 NUnit/MSTest 的 Assert 不要混用
Debug.Assert 是 .NET 运行时级的调试断言，依赖 DEBUG 编译符号，且失败时弹 Windows 对话框（或静默忽略），和单元测试框架的 Assert 完全无关。
- NUnit 的
Assert类属于测试生命周期管理，失败会标记测试为 Failed 并继续执行后续断言（除非配置了Assert.Fail强制中断） -
Debug.Assert在 Release 下编译器直接剔除整行，毫无存在感；而测试框架的Assert在 Release 下照常运行（只要测试项目本身是 Debug 或 Release 都无所谓） - 别在测试方法里写
Debug.Assert来替代框架断言——它不会让测试失败，也不会出现在测试报告里
最常被忽略的一点：断言失败后，NUnit 默认继续执行当前测试方法里的后续语句。这意味着如果前面的 Assert 没过，后面的代码仍可能抛出 NullReferenceException，掩盖真实问题。需要严格顺序依赖时，得靠逻辑分段或显式 return 控制流。
