用 dotnet test 运行首个单元测试需先验证环境，推荐 dotnet new xunit 创建项目，确保引用 Microsoft.NET.Test.Sdk、测试类和方法均为 public、使用 [Fact]；断言优先选 Assert.Equal（简单类型/已实现相等比较），逻辑判断用 Assert.True；集合比较须用 Assert.Collection 或 SequenceEqual；[Theory] + [InlineData] 提升可维护性；异步测试必须返回 async Task，禁用 async void 和 .Wait()。
怎么用 dotnet test 跑起第一个单元测试
不是先装什么插件，也不是配 .csproj，而是直接从命令行验证环境是否就绪。c# 单元测试默认依赖 xunit、nunit 或 mstest 三选一，但 dotnet new xunit 是最轻量且跨平台兼容性最好的起点。
常见错误现象：dotnet test 报错 “No test is available”，大概率是没在测试项目里引用 Microsoft.NET.Test.Sdk，或者 [Fact] 方法没写在 public 类里。
- 新建测试项目：执行
dotnet new xunit -n MyLib.Tests - 添加对被测项目的引用：
dotnet add reference ../MyLib/MyLib.csproj - 确保测试方法带
[Fact]（不是[Test]），类是public，方法是public void - 运行：
dotnet test—— 不要加--no-build，除非你确定刚编译过
Assert.Equal 和 Assert.True 该怎么选
不是“越严格越好”，而是看断言目标是否可比较、是否需要诊断信息。比如比较两个自定义对象时，Assert.Equal 会尝试调用 Equals，但若没重载，它就只比引用；而 Assert.True(obj1.Equals(obj2)) 看似一样，实际抛异常时根本看不出哪两个字段不等。
使用场景：返回值是简单类型（int、string、DateTime）或已实现 IEquatable<t></t> 的类，优先用 Assert.Equal；判断布尔逻辑分支（如 result.IsValid）、或需自定义判断逻辑（如“时间差小于500ms”），才用 Assert.True + 表达式。
-
Assert.Equal(42, result.Value)—— 错误时提示 “Expected: 42, Actual: 43” Assert.True(Math.Abs((result.Time - DateTime.Now).TotalMilliseconds) —— 错误时只报 “Assert.True failed”，得自己加 <code>message:参数才能看清上下文- 比较集合别用
Assert.Equal(list1, list2)直接比引用，要用Assert.Collection或list1.OrderBy(x => x.Id).SequenceEqual(list2.OrderBy(x => x.Id))
为什么 [Theory] + [InlineData] 比写十个 [Fact] 更可靠
因为重复逻辑分散在多个方法里，一旦被测函数签名改了（比如加个 bool includeNulls = false 参数），十个方法全得手动改调用，漏一个就埋下静默缺陷。而 [Theory] 把输入和预期打包成数据集，编译器能检查参数数量/类型，IDE 也能高亮出参不匹配的地方。
性能影响几乎为零，但可维护性差别巨大。注意 [InlineData] 只支持编译期常量（不能传 new DateTime() 或变量），复杂输入得用 [MemberData] 或 [ClassData]。
- 安全的
[InlineData]：[InlineData(1, "a", true)]、[InlineData(null, "b")] - 非法写法：
[InlineData(DateTime.Now)]（编译失败）、[InlineData(myVar)]（编译失败） - 需要动态数据时，定义静态属性返回
IEnumerable<object></object>，再用[MemberData(nameof(TestCases))]
测试异步方法时 async Task 和 void 写法的区别很致命
写成 public async void TestMethod() 看似能跑通，但测试框架根本等不到它结束 —— void 方法无法 await，框架认为“方法已执行完”，后续 Assert 全部被跳过，测试永远绿，问题永远藏住。
所有测试方法签名必须是 public async Task，且内部用 await 调用被测异步方法。xUnit 会等待这个 Task 完成才判定测试成败。
- ✅ 正确：
public async Task ReturnsCorrectResult_WhenCalledAsync() { var result = await _service.DoWorkAsync(); Assert.Equal("ok", result); } - ❌ 危险：
public async void ReturnsCorrectResult_WhenCalledAsync() { ... }—— 断言可能根本没执行 - ⚠️ 注意：不要在测试里用
.Wait()或.Result，会死锁（尤其在 UI 或 ASP.NET Core 默认同步上下文里）
测试里最容易被忽略的，是异步方法的取消令牌（CancellationToken）传递是否完整、以及异常路径是否真被触发 —— 很多 Assert.ThrowsAsync<t>()</t> 写着写着就变成了 Assert.Throws<t>()</t>，结果异步异常被吞掉，测试形同虚设。
