尧图网页设计 
使用 MSTest 3.x/4.x 编写现代 .NET 单元测试基于 awesome-copilot csharp-mstest Skill 的最佳实践实战指南【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本篇技术指南以 awesome-copilot 仓库中 csharp-mstest Skill 为核心骨架系统讲解如何用 MSTest 3.x/4.x 编写高质量单元测试从项目搭建、测试类结构与生命周期到现代断言 API、数据驱动测试、TestContext 高级用法与并行化控制。读完本文你将掌握一套可直接落地、可被 AI 编程助手GitHub Copilot与团队复用的 MSTest 现代测试范式并规避最常见的历史遗留反模式。一、Skill 定位Copilot 与开发者的 MSTest 规范源在 awesome-copilot 仓库中csharp-mstest是一个面向 GitHub Copilot 的 Skill技能指令其 frontmatter 声明如下--- name: csharp-mstest description: Get best practices for MSTest 3.x/4.x unit testing, including modern assertion APIs and>[TestClass] public sealed class CalculatorTests { [TestMethod] public void Add_TwoPositiveNumbers_ReturnsSum() { // Arrange var calculator new Calculator(); // Act var result calculator.Add(2, 3); // Assert Assert.AreEqual(5, result); } }这一约定在仓库的 C# 专家 Agent 中同样被固化agents/CSharpExpert.agent.md 明确指出 MSTest 的类标记是[TestClass]、方法标记是[TestMethod]、参数化测试应使用[TestMethod][DataRow]。两份文档相互印证说明这是仓库维护者认可的团队级规范。四、测试生命周期构造器优先初始化/清理各司其职MSTest 为每个测试方法提供了一整套生命周期钩子但现代最佳实践对其使用有明确取舍优先使用构造函数做常规初始化而不是[TestInitialize]。构造器可以配合readonly字段遵循标准 C# 模式且每个测试方法执行前都会构造一个新的测试类实例天然保证测试间隔离[TestInitialize]保留给无法在构造器中完成的初始化典型场景是异步初始化构造函数不能await[TestCleanup]用于即使测试失败也必须执行的清理逻辑如释放外部资源、重置状态。[TestClass] public sealed class ServiceTests { private readonly MyService _service; // readonly enabled by constructor public ServiceTests() { _service new MyService(); } [TestInitialize] public async Task InitAsync() { // Use for async initialization only await _service.WarmupAsync(); } [TestCleanup] public void Cleanup() _service.Reset(); }执行顺序七步全景MSTest 的完整执行顺序如下理解它才能准确判断哪段代码在什么时候跑、共享哪些状态Assembly 级初始化[AssemblyInitialize]在整个测试程序集内仅执行一次Class 级初始化[ClassInitialize]在每个测试类内仅执行一次每个测试方法的初始化阶段执行构造函数设置TestContext属性执行[TestInitialize]测试执行运行测试方法本身每个测试方法的清理阶段执行[TestCleanup]若实现DisposeAsync则调用之若实现Dispose则调用之Class 级清理[ClassCleanup]在每个测试类内仅执行一次Assembly 级清理[AssemblyCleanup]在整个测试程序集内仅执行一次。这条顺序链意味着构造函数 [TestInitialize]的组合可以实现先构造普通依赖、再做异步预热的灵活初始化而DisposeAsync/Dispose排在[TestCleanup]之后适合承载基于 IDisposable 的通用资源释放。五、现代断言 API 全景MSTest 提供三个断言类Assert、StringAssert和CollectionAssert。核心原则是能用Assert类等价 API 解决的优先用Assert例如Assert.Contains(expected, actual)优于StringAssert.Contains(actual, expected)后者仅在无等价替代时才使用。5.1 Assert 类核心断言// Equality Assert.AreEqual(expected, actual); Assert.AreNotEqual(notExpected, actual); Assert.AreSame(expectedObject, actualObject); // Reference equality Assert.AreNotSame(notExpectedObject, actualObject); // Null checks Assert.IsNull(value); Assert.IsNotNull(value); // Boolean Assert.IsTrue(condition); Assert.IsFalse(condition); // Fail/Inconclusive Assert.Fail(Test failed due to...); Assert.Inconclusive(Test cannot be completed because...);注意参数顺序Assert.AreEqual(expected, actual)期望值在前、实际值在后。顺序写反是 MSTest 最常见的错误之一会直接导致失败信息语义颠倒详见第九节的常见错误清单。5.2 异常测试优先 Assert.Throws放弃 [ExpectedException]传统的[ExpectedException]特性存在明显缺陷它无法精确断言异常发生的位置、无法校验异常消息且一个方法只能声明一种预期。现代写法是使用Assert.Throws系列// Assert.Throws - matches TException or derived types var ex Assert.ThrowsArgumentException(() Method(null)); Assert.AreEqual(Value cannot be null., ex.Message); // Assert.ThrowsExactly - matches exact type only var ex Assert.ThrowsExactlyInvalidOperationException(() Method()); // Async versions var ex await Assert.ThrowsAsyncHttpRequestException(async () await client.GetAsync(url)); var ex await Assert.ThrowsExactlyAsyncInvalidOperationException(async () await Method());ThrowsT允许派生类型抛出的异常是T或其子类都算命中ThrowsExactlyT只匹配精确类型ThrowsAsync/ThrowsExactlyAsync用于async方法。返回的异常对象可以被继续断言例如校验Message、InnerException或自定义属性这是[ExpectedException]完全做不到的。仓库的 agents/CSharpExpert.agent.md 同样建议优先使用Throws/ThrowsAsync类 API 处理异常断言与该规范完全一致。5.3 集合断言Assert 类Assert.Contains(expectedItem, collection); Assert.DoesNotContain(unexpectedItem, collection); Assert.ContainsSingle(collection); // exactly one element Assert.HasCount(5, collection); Assert.IsEmpty(collection); Assert.IsNotEmpty(collection);其中Assert.ContainsSingle尤其值得关注它比 LINQ 的Single()提供更清晰的失败信息见常见错误章节是断言集合恰好含一个元素的首选。5.4 字符串断言Assert 类Assert.Contains(expected, actualString); Assert.StartsWith(prefix, actualString); Assert.EndsWith(suffix, actualString); Assert.DoesNotStartWith(prefix, actualString); Assert.DoesNotEndWith(suffix, actualString); Assert.MatchesRegex(\d{3}-\d{4}, phoneNumber); Assert.DoesNotMatchRegex(\d, textOnly);MatchesRegex/DoesNotMatchRegex让字符串断言从精确匹配扩展到模式匹配非常适合校验电话号码、邮箱、编号等格式类输出。5.5 比较断言Assert.IsGreaterThan(lowerBound, actual); Assert.IsGreaterThanOrEqualTo(lowerBound, actual); Assert.IsLessThan(upperBound, actual); Assert.IsLessThanOrEqualTo(upperBound, actual); Assert.IsInRange(actual, low, high); Assert.IsPositive(number); Assert.IsNegative(number);这套 API 取代了用Assert.IsTrue(a b)的旧写法——失败时你能看到完整的比较上下文与期望/实际值而不是一个没有信息的布尔断言。5.6 类型断言3.x 与 4.x 的差异类型断言在 MSTest 3.x 与 4.x 之间存在破坏性 API 差异写代码前务必确认目标版本// MSTest 3.x - uses out parameter Assert.IsInstanceOfTypeMyClass(obj, out var typed); typed.DoSomething(); // MSTest 4.x - returns typed result directly var typed Assert.IsInstanceOfTypeMyClass(obj); typed.DoSomething(); Assert.IsNotInstanceOfTypeWrongType(obj);3.x 通过out var把类型化结果带出4.x 改为直接返回强类型结果。迁移到 4.x 时所有Assert.IsInstanceOfTypeT(obj, out var x)的调用点都需要改写。5.7 Assert.ThatMSTest 4.0Assert.That(result.Count 0); // Auto-captures expression in failure messageAssert.That接受任意布尔表达式并在失败时自动捕获并回显表达式本身作为失败信息适合一次性、临时性或复杂条件断言。5.8 StringAssert 类传统 API谨慎使用提示优先使用Assert类的等价 API如Assert.Contains(expected, actual)优于StringAssert.Contains(actual, expected)。StringAssert.Contains(actualString, expected); StringAssert.StartsWith(actualString, prefix); StringAssert.EndsWith(actualString, suffix); StringAssert.Matches(actualString, new Regex(\d{3}-\d{4})); StringAssert.DoesNotMatch(actualString, new Regex(\d));注意StringAssert的参数顺序与Assert版相反实际值在前这正是不建议混用的原因之一——两套 API 并存极易写错参数顺序。5.9 CollectionAssert 类传统 API谨慎使用提示优先使用Assert类的等价 API如Assert.Contains。// Containment CollectionAssert.Contains(collection, expectedItem); CollectionAssert.DoesNotContain(collection, unexpectedItem); // Equality (same elements, same order) CollectionAssert.AreEqual(expectedCollection, actualCollection); CollectionAssert.AreNotEqual(unexpectedCollection, actualCollection); // Equivalence (same elements, any order) CollectionAssert.AreEquivalent(expectedCollection, actualCollection); CollectionAssert.AreNotEquivalent(unexpectedCollection, actualCollection); // Subset checks CollectionAssert.IsSubsetOf(subset, superset); CollectionAssert.IsNotSubsetOf(notSubset, collection); // Element validation CollectionAssert.AllItemsAreInstancesOfType(collection, typeof(MyClass)); CollectionAssert.AllItemsAreNotNull(collection); CollectionAssert.AllItemsAreUnique(collection);需要区分两组极易混淆的 APIAreEqual要求元素相同且顺序一致AreEquivalent只要求元素集合相同、顺序无关。六、数据驱动测试数据驱动测试让同一逻辑、多组输入的测试需求得以用最小代码量覆盖。MSTest 提供[DataRow]与[DynamicData]两条路线。6.1 DataRow静态内联数据[TestMethod] [DataRow(1, 2, 3)] [DataRow(0, 0, 0, DisplayName Zeros)] [DataRow(-1, 1, 0, IgnoreMessage Known issue #123)] // MSTest 3.8 public void Add_ReturnsSum(int a, int b, int expected) { Assert.AreEqual(expected, Calculator.Add(a, b)); }DisplayName自定义该行的显示名称便于在测试报告中识别IgnoreMessageMSTest 3.8为单行数据提供跳过原因说明替代整方法级别的[Ignore]适合已知问题未修复但其余行仍需回归的场景。6.2 DynamicData动态数据源[DynamicData]的数据源方法可以返回以下四种类型官方推荐度从高到低返回类型类型安全附加能力说明IEnumerable(T1, T2, ...)ValueTuple✅—首选MSTest 3.7IEnumerableTupleT1, T2, ...✅—类型安全IEnumerableTestDataRow✅显示名、分类等元数据需要元数据时选用IEnumerableobject[]❌—最不推荐无编译期类型检查重要新建测试数据方法时优先选择ValueTuple或TestDataRow避免IEnumerableobject[]。object[]方案没有编译期类型检查类型不匹配只能在运行时暴露且错误定位困难。[TestMethod] [DynamicData(nameof(TestData))] public void DynamicTest(int a, int b, int expected) { Assert.AreEqual(expected, Calculator.Add(a, b)); } // ValueTuple - preferred (MSTest 3.7) public static IEnumerable(int a, int b, int expected) TestData [ (1, 2, 3), (0, 0, 0), ]; // TestDataRow - when you need custom display names or metadata public static IEnumerableTestDataRow(int a, int b, int expected) TestDataWithMetadata [ new((1, 2, 3)) { DisplayName Positive numbers }, new((0, 0, 0)) { DisplayName Zeros }, new((-1, 1, 0)) { DisplayName Mixed signs, IgnoreMessage Known issue #123 }, ]; // IEnumerableobject[] - avoid for new code (no type safety) public static IEnumerableobject[] LegacyTestData [ [1, 2, 3], [0, 0, 0], ];TestDataRow的IgnoreMessage与[DataRow]相同同样是 MSTest 3.8 的能力可用于按行跳过已知问题数据。数据源成员是static属性/方法因为 MSTest 需要在不实例化测试类的情况下枚举数据。七、TestContext运行信息、取消与输出TestContext提供测试运行信息、取消支持与输出方法是编写健壮测试尤其超时控制、CI 日志、结果文件的核心入口。7.1 获取 TestContext 的三种方式// Property (MSTest suppresses CS8618 - dont use nullable or null!) public TestContext TestContext { get; set; } // Constructor injection (MSTest 3.6) - preferred for immutability [TestClass] public sealed class MyTests { private readonly TestContext _testContext; public MyTests(TestContext testContext) { _testContext testContext; } } // Static methods receive it as parameter [ClassInitialize] public static void ClassInit(TestContext context) { } // Optional for cleanup methods (MSTest 3.6) [ClassCleanup] public static void ClassCleanup(TestContext context) { } [AssemblyCleanup] public static void AssemblyCleanup(TestContext context) { }三种方式对应三种场景属性注入是经典写法MSTest 会抑制 CS8618 警告无需 null!或可空标记详见常见错误构造器注入MSTest 3.6用readonly字段换取了不可变性是推荐的新写法静态初始化/清理方法则通过参数接收。7.2 取消令牌与 [Timeout] 协作始终使用TestContext.CancellationToken进行协作式取消并配合[Timeout]超时特性[TestMethod] [Timeout(5000)] public async Task LongRunningTest() { await _httpClient.GetAsync(url, TestContext.CancellationToken); }当测试超时被中止时MSTest 会通过该令牌向异步调用链发出取消信号让 HTTP 请求、数据库查询等长任务得以优雅终止而不是被粗暴打断。7.3 测试运行属性TestContext.TestName // Current test method name TestContext.TestDisplayName // Display name (3.7) TestContext.CurrentTestOutcome // Pass/Fail/InProgress TestContext.TestData // Parameterized test data (3.7, in TestInitialize/Cleanup) TestContext.TestException // Exception if test failed (3.7, in TestCleanup) TestContext.DeploymentDirectory // Directory with deployment itemsTestData与TestException是 3.7 的增强前者让初始化/清理阶段也能感知当前参数化测试行的数据后者允许在[TestCleanup]中读取失败异常做附加处理如生成失败现场快照。7.4 输出与结果文件// Write to test output (useful for debugging) TestContext.WriteLine(Processing item {0}, itemId); // Attach files to test results (logs, screenshots) TestContext.AddResultFile(screenshotPath); // Store/retrieve data across test methods TestContext.Properties[SharedKey] computedValue;WriteLine支持格式化字符串{0}占位输出会出现在dotnet test的详细日志与测试报告中AddResultFile把截图、日志等文件附加到测试结果是 UI/集成类测试的必备能力Properties是一个键值字典可在同一测试方法的不同阶段间共享数据。八、高级特性重试、条件执行、并行化与工作项追踪8.1 重试不稳定测试MSTest 3.9[TestMethod] [Retry(3)] public void FlakyTest() { }[Retry(3)]让不稳定测试最多重试 3 次。它是对不可控环境导致的偶发失败的兜底手段不应替代对根本原因的修复——重试适用于确属环境抖动的场景而不是掩盖逻辑缺陷。8.2 条件执行MSTest 3.10按操作系统或 CI 环境跳过/运行测试// OS-specific tests [TestMethod] [OSCondition(OperatingSystems.Windows)] public void WindowsOnlyTest() { } [TestMethod] [OSCondition(OperatingSystems.Linux | OperatingSystems.MacOS)] public void UnixOnlyTest() { } [TestMethod] [OSCondition(ConditionMode.Exclude, OperatingSystems.Windows)] public void SkipOnWindowsTest() { } // CI environment tests [TestMethod] [CICondition] // Runs only in CI (default: ConditionMode.Include) public void CIOnlyTest() { } [TestMethod] [CICondition(ConditionMode.Exclude)] // Skips in CI, runs locally public void LocalOnlyTest() { }OperatingSystems是一个支持按位或|组合的枚举ConditionMode.Include/Exclude控制满足条件则运行/满足条件则跳过。这取代了以往靠#if预编译指令或环境变量判断的笨拙写法。8.3 并行化// Assembly level [assembly: Parallelize(Workers 4, Scope ExecutionScope.MethodLevel)] // Disable for specific class [TestClass] [DoNotParallelize] public sealed class SequentialTests { }程序集级[Parallelize]设定并行工作线程数与并行粒度MethodLevel表示方法级并行对依赖共享状态、无法并发的类用[DoNotParallelize]单独降级为串行执行。8.4 工作项追踪MSTest 3.8把测试与需求/缺陷工作项关联实现可追溯性// Azure DevOps work items [TestMethod] [WorkItem(12345)] // Links to work item #12345 public void Feature_Scenario_ExpectedBehavior() { } // Multiple work items [TestMethod] [WorkItem(12345)] [WorkItem(67890)] public void Feature_CoversMultipleRequirements() { } // GitHub issues (MSTest 3.8) [TestMethod] [GitHubWorkItem(https://github.com/owner/repo/issues/42)] public void BugFix_Issue42_IsResolved() { }工作项关联会出现在测试结果中可用于将测试覆盖追踪到具体需求把缺陷修复与回归测试关联起来在 CI/CD 流水线中生成追溯性报告。九、常见错误清单反模式对照这份清单浓缩了 MSTest 实践中最容易踩的坑建议作为 Code Review 时的对照表// ❌ Wrong argument order Assert.AreEqual(actual, expected); // ✅ Correct Assert.AreEqual(expected, actual); // ❌ Using ExpectedException (obsolete) [ExpectedException(typeof(ArgumentException))] // ✅ Use Assert.Throws Assert.ThrowsArgumentException(() Method()); // ❌ Using LINQ Single() - unclear exception var item items.Single(); // ✅ Use ContainsSingle - better failure message var item Assert.ContainsSingle(items); // ❌ Hard cast - unclear exception var handler (MyHandler)result; // ✅ Type assertion - shows actual type on failure var handler Assert.IsInstanceOfTypeMyHandler(result); // ❌ Ignoring cancellation token await client.GetAsync(url, CancellationToken.None); // ✅ Flow test cancellation await client.GetAsync(url, TestContext.CancellationToken); // ❌ Making TestContext nullable - leads to unnecessary null checks public TestContext? TestContext { get; set; } // ❌ Using null! - MSTest already suppresses CS8618 for this property public TestContext TestContext { get; set; } null!; // ✅ Declare without nullable or initializer - MSTest handles the warning public TestContext TestContext { get; set; }逐条解读其中的设计逻辑AreEqual(actual, expected)期望/实际顺序颠倒后失败消息中的Expected/Actual含义会被反转误导排错方向[ExpectedException]已过时无法断言异常细节与发生位置用Assert.Throws系列替代Single()失败时抛出的InvalidOperationException信息含糊Assert.ContainsSingle会给出包含集合内容与期望的失败消息硬转换(MyHandler)result类型不符时抛出难以理解的InvalidCastExceptionAssert.IsInstanceOfType失败时会显示实际类型CancellationToken.None丢弃了 MSTest 提供的取消信号超时/中断时无法协作式取消改用TestContext.CancellationTokenTestContext声明MSTest 已为属性注入抑制 CS8618 警告写成 null!反而留下不必要的空值暗示可空标记则迫使你在所有调用点做无意义判空——正确写法就是朴素声明。十、测试组织与 Mocking10.1 组织与筛选按功能或组件分组测试保持测试代码与生产代码结构对应用[TestCategory(Category)]给测试打分类标签配合dotnet test --filter TestCategoryCategory实现按类别运行如区分 Unit/Integration/Smoke用[TestProperty(Name, Value)]附加自定义元数据例如[TestProperty(Bug, 12345)]将测试与缺陷单号关联用[Priority(1)]标记关键测试数字越小优先级越高便于快速圈定必须通过的核心集启用相关的 MSTest 分析器规则尤其MSTEST0020建议用构造函数替代[TestInitialize]让编译期自动约束团队写法。这与 Skill 中优先构造器的约定前后呼应。10.2 Mocking 与隔离使用Moq 或 NSubstitute模拟依赖通过接口暴露依赖以便模拟面向接口编程是模拟的前提模拟依赖以隔离被测单元让测试只验证目标类的行为而不受外部系统影响。仓库 agents/CSharpExpert.agent.md 对 Mocking 有更进一步的工程约束优先避免 mock外部依赖才可 mock绝不 mock 被测解决方案内部实现并建议为 mock 与被模拟依赖的输出一致性补充测试。这条纪律与隔离被测单元的原则一脉相承可作为团队 Mocking 策略的补充红线。十一、在 Copilot 工作流中使用本指南csharp-mstestSkill 在仓库中的真实使用方式是开发者或 CI 中的 Agent触发该 Skill 后Copilot 会遵循本指南的规范生成/审查测试代码。其落地链路为安装gh skills install github/awesome-copilot csharp-mstest见 docs/README.skills.md通过csharp-dotnet-development插件统一接入多个 C# 技能见 plugins/csharp-dotnet-development/plugin.jsonCopilot 在编写 MSTest 代码时自动应用本文的全部规范构造器初始化、Assert.Throws、ValueTuple 数据源、TestContext.CancellationToken、分析器启用等。由此给 Copilot 下指令与团队测试规范落地被统一到同一份文档中——这正是该 Skill 的设计价值。结语从项目搭建、测试生命周期到三套断言类、两类数据驱动写法再到TestContext取消机制、重试/条件执行/并行化等高级特性这份基于 awesome-copilot 仓库 csharp-mstest Skill 的指南覆盖了 MSTest 3.x/4.x 现代开发的完整知识面。核心要点可归纳为五条测试类 sealed AAA 规范命名、构造器优先于[TestInitialize]、断言一律走现代 APIThrows / ContainsSingle / IsInstanceOfType、数据驱动用 ValueTuple 或 TestDataRow、始终流动TestContext.CancellationToken。把这份规范沉淀进团队与 AI 助手的共享指令你就拥有了可规模化复制的 .NET 单元测试质量基线。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 MSTest 3.x/4.x 编写现代 .NET 单元测试：基于 awesome-copilot csharp-mstest Skill 的最佳实践实战指南
使用 MSTest 3.x/4.x 编写现代 .NET 单元测试基于 awesome-copilot csharp-mstest Skill 的最佳实践实战指南【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本篇技术指南以 awesome-copilot 仓库中 csharp-mstest Skill 为核心骨架系统讲解如何用 MSTest 3.x/4.x 编写高质量单元测试从项目搭建、测试类结构与生命周期到现代断言 API、数据驱动测试、TestContext 高级用法与并行化控制。读完本文你将掌握一套可直接落地、可被 AI 编程助手GitHub Copilot与团队复用的 MSTest 现代测试范式并规避最常见的历史遗留反模式。一、Skill 定位Copilot 与开发者的 MSTest 规范源在 awesome-copilot 仓库中csharp-mstest是一个面向 GitHub Copilot 的 Skill技能指令其 frontmatter 声明如下--- name: csharp-mstest description: Get best practices for MSTest 3.x/4.x unit testing, including modern assertion APIs and>[TestClass] public sealed class CalculatorTests { [TestMethod] public void Add_TwoPositiveNumbers_ReturnsSum() { // Arrange var calculator new Calculator(); // Act var result calculator.Add(2, 3); // Assert Assert.AreEqual(5, result); } }这一约定在仓库的 C# 专家 Agent 中同样被固化agents/CSharpExpert.agent.md 明确指出 MSTest 的类标记是[TestClass]、方法标记是[TestMethod]、参数化测试应使用[TestMethod][DataRow]。两份文档相互印证说明这是仓库维护者认可的团队级规范。四、测试生命周期构造器优先初始化/清理各司其职MSTest 为每个测试方法提供了一整套生命周期钩子但现代最佳实践对其使用有明确取舍优先使用构造函数做常规初始化而不是[TestInitialize]。构造器可以配合readonly字段遵循标准 C# 模式且每个测试方法执行前都会构造一个新的测试类实例天然保证测试间隔离[TestInitialize]保留给无法在构造器中完成的初始化典型场景是异步初始化构造函数不能await[TestCleanup]用于即使测试失败也必须执行的清理逻辑如释放外部资源、重置状态。[TestClass] public sealed class ServiceTests { private readonly MyService _service; // readonly enabled by constructor public ServiceTests() { _service new MyService(); } [TestInitialize] public async Task InitAsync() { // Use for async initialization only await _service.WarmupAsync(); } [TestCleanup] public void Cleanup() _service.Reset(); }执行顺序七步全景MSTest 的完整执行顺序如下理解它才能准确判断哪段代码在什么时候跑、共享哪些状态Assembly 级初始化[AssemblyInitialize]在整个测试程序集内仅执行一次Class 级初始化[ClassInitialize]在每个测试类内仅执行一次每个测试方法的初始化阶段执行构造函数设置TestContext属性执行[TestInitialize]测试执行运行测试方法本身每个测试方法的清理阶段执行[TestCleanup]若实现DisposeAsync则调用之若实现Dispose则调用之Class 级清理[ClassCleanup]在每个测试类内仅执行一次Assembly 级清理[AssemblyCleanup]在整个测试程序集内仅执行一次。这条顺序链意味着构造函数 [TestInitialize]的组合可以实现先构造普通依赖、再做异步预热的灵活初始化而DisposeAsync/Dispose排在[TestCleanup]之后适合承载基于 IDisposable 的通用资源释放。五、现代断言 API 全景MSTest 提供三个断言类Assert、StringAssert和CollectionAssert。核心原则是能用Assert类等价 API 解决的优先用Assert例如Assert.Contains(expected, actual)优于StringAssert.Contains(actual, expected)后者仅在无等价替代时才使用。5.1 Assert 类核心断言// Equality Assert.AreEqual(expected, actual); Assert.AreNotEqual(notExpected, actual); Assert.AreSame(expectedObject, actualObject); // Reference equality Assert.AreNotSame(notExpectedObject, actualObject); // Null checks Assert.IsNull(value); Assert.IsNotNull(value); // Boolean Assert.IsTrue(condition); Assert.IsFalse(condition); // Fail/Inconclusive Assert.Fail(Test failed due to...); Assert.Inconclusive(Test cannot be completed because...);注意参数顺序Assert.AreEqual(expected, actual)期望值在前、实际值在后。顺序写反是 MSTest 最常见的错误之一会直接导致失败信息语义颠倒详见第九节的常见错误清单。5.2 异常测试优先 Assert.Throws放弃 [ExpectedException]传统的[ExpectedException]特性存在明显缺陷它无法精确断言异常发生的位置、无法校验异常消息且一个方法只能声明一种预期。现代写法是使用Assert.Throws系列// Assert.Throws - matches TException or derived types var ex Assert.ThrowsArgumentException(() Method(null)); Assert.AreEqual(Value cannot be null., ex.Message); // Assert.ThrowsExactly - matches exact type only var ex Assert.ThrowsExactlyInvalidOperationException(() Method()); // Async versions var ex await Assert.ThrowsAsyncHttpRequestException(async () await client.GetAsync(url)); var ex await Assert.ThrowsExactlyAsyncInvalidOperationException(async () await Method());ThrowsT允许派生类型抛出的异常是T或其子类都算命中ThrowsExactlyT只匹配精确类型ThrowsAsync/ThrowsExactlyAsync用于async方法。返回的异常对象可以被继续断言例如校验Message、InnerException或自定义属性这是[ExpectedException]完全做不到的。仓库的 agents/CSharpExpert.agent.md 同样建议优先使用Throws/ThrowsAsync类 API 处理异常断言与该规范完全一致。5.3 集合断言Assert 类Assert.Contains(expectedItem, collection); Assert.DoesNotContain(unexpectedItem, collection); Assert.ContainsSingle(collection); // exactly one element Assert.HasCount(5, collection); Assert.IsEmpty(collection); Assert.IsNotEmpty(collection);其中Assert.ContainsSingle尤其值得关注它比 LINQ 的Single()提供更清晰的失败信息见常见错误章节是断言集合恰好含一个元素的首选。5.4 字符串断言Assert 类Assert.Contains(expected, actualString); Assert.StartsWith(prefix, actualString); Assert.EndsWith(suffix, actualString); Assert.DoesNotStartWith(prefix, actualString); Assert.DoesNotEndWith(suffix, actualString); Assert.MatchesRegex(\d{3}-\d{4}, phoneNumber); Assert.DoesNotMatchRegex(\d, textOnly);MatchesRegex/DoesNotMatchRegex让字符串断言从精确匹配扩展到模式匹配非常适合校验电话号码、邮箱、编号等格式类输出。5.5 比较断言Assert.IsGreaterThan(lowerBound, actual); Assert.IsGreaterThanOrEqualTo(lowerBound, actual); Assert.IsLessThan(upperBound, actual); Assert.IsLessThanOrEqualTo(upperBound, actual); Assert.IsInRange(actual, low, high); Assert.IsPositive(number); Assert.IsNegative(number);这套 API 取代了用Assert.IsTrue(a b)的旧写法——失败时你能看到完整的比较上下文与期望/实际值而不是一个没有信息的布尔断言。5.6 类型断言3.x 与 4.x 的差异类型断言在 MSTest 3.x 与 4.x 之间存在破坏性 API 差异写代码前务必确认目标版本// MSTest 3.x - uses out parameter Assert.IsInstanceOfTypeMyClass(obj, out var typed); typed.DoSomething(); // MSTest 4.x - returns typed result directly var typed Assert.IsInstanceOfTypeMyClass(obj); typed.DoSomething(); Assert.IsNotInstanceOfTypeWrongType(obj);3.x 通过out var把类型化结果带出4.x 改为直接返回强类型结果。迁移到 4.x 时所有Assert.IsInstanceOfTypeT(obj, out var x)的调用点都需要改写。5.7 Assert.ThatMSTest 4.0Assert.That(result.Count 0); // Auto-captures expression in failure messageAssert.That接受任意布尔表达式并在失败时自动捕获并回显表达式本身作为失败信息适合一次性、临时性或复杂条件断言。5.8 StringAssert 类传统 API谨慎使用提示优先使用Assert类的等价 API如Assert.Contains(expected, actual)优于StringAssert.Contains(actual, expected)。StringAssert.Contains(actualString, expected); StringAssert.StartsWith(actualString, prefix); StringAssert.EndsWith(actualString, suffix); StringAssert.Matches(actualString, new Regex(\d{3}-\d{4})); StringAssert.DoesNotMatch(actualString, new Regex(\d));注意StringAssert的参数顺序与Assert版相反实际值在前这正是不建议混用的原因之一——两套 API 并存极易写错参数顺序。5.9 CollectionAssert 类传统 API谨慎使用提示优先使用Assert类的等价 API如Assert.Contains。// Containment CollectionAssert.Contains(collection, expectedItem); CollectionAssert.DoesNotContain(collection, unexpectedItem); // Equality (same elements, same order) CollectionAssert.AreEqual(expectedCollection, actualCollection); CollectionAssert.AreNotEqual(unexpectedCollection, actualCollection); // Equivalence (same elements, any order) CollectionAssert.AreEquivalent(expectedCollection, actualCollection); CollectionAssert.AreNotEquivalent(unexpectedCollection, actualCollection); // Subset checks CollectionAssert.IsSubsetOf(subset, superset); CollectionAssert.IsNotSubsetOf(notSubset, collection); // Element validation CollectionAssert.AllItemsAreInstancesOfType(collection, typeof(MyClass)); CollectionAssert.AllItemsAreNotNull(collection); CollectionAssert.AllItemsAreUnique(collection);需要区分两组极易混淆的 APIAreEqual要求元素相同且顺序一致AreEquivalent只要求元素集合相同、顺序无关。六、数据驱动测试数据驱动测试让同一逻辑、多组输入的测试需求得以用最小代码量覆盖。MSTest 提供[DataRow]与[DynamicData]两条路线。6.1 DataRow静态内联数据[TestMethod] [DataRow(1, 2, 3)] [DataRow(0, 0, 0, DisplayName Zeros)] [DataRow(-1, 1, 0, IgnoreMessage Known issue #123)] // MSTest 3.8 public void Add_ReturnsSum(int a, int b, int expected) { Assert.AreEqual(expected, Calculator.Add(a, b)); }DisplayName自定义该行的显示名称便于在测试报告中识别IgnoreMessageMSTest 3.8为单行数据提供跳过原因说明替代整方法级别的[Ignore]适合已知问题未修复但其余行仍需回归的场景。6.2 DynamicData动态数据源[DynamicData]的数据源方法可以返回以下四种类型官方推荐度从高到低返回类型类型安全附加能力说明IEnumerable(T1, T2, ...)ValueTuple✅—首选MSTest 3.7IEnumerableTupleT1, T2, ...✅—类型安全IEnumerableTestDataRow✅显示名、分类等元数据需要元数据时选用IEnumerableobject[]❌—最不推荐无编译期类型检查重要新建测试数据方法时优先选择ValueTuple或TestDataRow避免IEnumerableobject[]。object[]方案没有编译期类型检查类型不匹配只能在运行时暴露且错误定位困难。[TestMethod] [DynamicData(nameof(TestData))] public void DynamicTest(int a, int b, int expected) { Assert.AreEqual(expected, Calculator.Add(a, b)); } // ValueTuple - preferred (MSTest 3.7) public static IEnumerable(int a, int b, int expected) TestData [ (1, 2, 3), (0, 0, 0), ]; // TestDataRow - when you need custom display names or metadata public static IEnumerableTestDataRow(int a, int b, int expected) TestDataWithMetadata [ new((1, 2, 3)) { DisplayName Positive numbers }, new((0, 0, 0)) { DisplayName Zeros }, new((-1, 1, 0)) { DisplayName Mixed signs, IgnoreMessage Known issue #123 }, ]; // IEnumerableobject[] - avoid for new code (no type safety) public static IEnumerableobject[] LegacyTestData [ [1, 2, 3], [0, 0, 0], ];TestDataRow的IgnoreMessage与[DataRow]相同同样是 MSTest 3.8 的能力可用于按行跳过已知问题数据。数据源成员是static属性/方法因为 MSTest 需要在不实例化测试类的情况下枚举数据。七、TestContext运行信息、取消与输出TestContext提供测试运行信息、取消支持与输出方法是编写健壮测试尤其超时控制、CI 日志、结果文件的核心入口。7.1 获取 TestContext 的三种方式// Property (MSTest suppresses CS8618 - dont use nullable or null!) public TestContext TestContext { get; set; } // Constructor injection (MSTest 3.6) - preferred for immutability [TestClass] public sealed class MyTests { private readonly TestContext _testContext; public MyTests(TestContext testContext) { _testContext testContext; } } // Static methods receive it as parameter [ClassInitialize] public static void ClassInit(TestContext context) { } // Optional for cleanup methods (MSTest 3.6) [ClassCleanup] public static void ClassCleanup(TestContext context) { } [AssemblyCleanup] public static void AssemblyCleanup(TestContext context) { }三种方式对应三种场景属性注入是经典写法MSTest 会抑制 CS8618 警告无需 null!或可空标记详见常见错误构造器注入MSTest 3.6用readonly字段换取了不可变性是推荐的新写法静态初始化/清理方法则通过参数接收。7.2 取消令牌与 [Timeout] 协作始终使用TestContext.CancellationToken进行协作式取消并配合[Timeout]超时特性[TestMethod] [Timeout(5000)] public async Task LongRunningTest() { await _httpClient.GetAsync(url, TestContext.CancellationToken); }当测试超时被中止时MSTest 会通过该令牌向异步调用链发出取消信号让 HTTP 请求、数据库查询等长任务得以优雅终止而不是被粗暴打断。7.3 测试运行属性TestContext.TestName // Current test method name TestContext.TestDisplayName // Display name (3.7) TestContext.CurrentTestOutcome // Pass/Fail/InProgress TestContext.TestData // Parameterized test data (3.7, in TestInitialize/Cleanup) TestContext.TestException // Exception if test failed (3.7, in TestCleanup) TestContext.DeploymentDirectory // Directory with deployment itemsTestData与TestException是 3.7 的增强前者让初始化/清理阶段也能感知当前参数化测试行的数据后者允许在[TestCleanup]中读取失败异常做附加处理如生成失败现场快照。7.4 输出与结果文件// Write to test output (useful for debugging) TestContext.WriteLine(Processing item {0}, itemId); // Attach files to test results (logs, screenshots) TestContext.AddResultFile(screenshotPath); // Store/retrieve data across test methods TestContext.Properties[SharedKey] computedValue;WriteLine支持格式化字符串{0}占位输出会出现在dotnet test的详细日志与测试报告中AddResultFile把截图、日志等文件附加到测试结果是 UI/集成类测试的必备能力Properties是一个键值字典可在同一测试方法的不同阶段间共享数据。八、高级特性重试、条件执行、并行化与工作项追踪8.1 重试不稳定测试MSTest 3.9[TestMethod] [Retry(3)] public void FlakyTest() { }[Retry(3)]让不稳定测试最多重试 3 次。它是对不可控环境导致的偶发失败的兜底手段不应替代对根本原因的修复——重试适用于确属环境抖动的场景而不是掩盖逻辑缺陷。8.2 条件执行MSTest 3.10按操作系统或 CI 环境跳过/运行测试// OS-specific tests [TestMethod] [OSCondition(OperatingSystems.Windows)] public void WindowsOnlyTest() { } [TestMethod] [OSCondition(OperatingSystems.Linux | OperatingSystems.MacOS)] public void UnixOnlyTest() { } [TestMethod] [OSCondition(ConditionMode.Exclude, OperatingSystems.Windows)] public void SkipOnWindowsTest() { } // CI environment tests [TestMethod] [CICondition] // Runs only in CI (default: ConditionMode.Include) public void CIOnlyTest() { } [TestMethod] [CICondition(ConditionMode.Exclude)] // Skips in CI, runs locally public void LocalOnlyTest() { }OperatingSystems是一个支持按位或|组合的枚举ConditionMode.Include/Exclude控制满足条件则运行/满足条件则跳过。这取代了以往靠#if预编译指令或环境变量判断的笨拙写法。8.3 并行化// Assembly level [assembly: Parallelize(Workers 4, Scope ExecutionScope.MethodLevel)] // Disable for specific class [TestClass] [DoNotParallelize] public sealed class SequentialTests { }程序集级[Parallelize]设定并行工作线程数与并行粒度MethodLevel表示方法级并行对依赖共享状态、无法并发的类用[DoNotParallelize]单独降级为串行执行。8.4 工作项追踪MSTest 3.8把测试与需求/缺陷工作项关联实现可追溯性// Azure DevOps work items [TestMethod] [WorkItem(12345)] // Links to work item #12345 public void Feature_Scenario_ExpectedBehavior() { } // Multiple work items [TestMethod] [WorkItem(12345)] [WorkItem(67890)] public void Feature_CoversMultipleRequirements() { } // GitHub issues (MSTest 3.8) [TestMethod] [GitHubWorkItem(https://github.com/owner/repo/issues/42)] public void BugFix_Issue42_IsResolved() { }工作项关联会出现在测试结果中可用于将测试覆盖追踪到具体需求把缺陷修复与回归测试关联起来在 CI/CD 流水线中生成追溯性报告。九、常见错误清单反模式对照这份清单浓缩了 MSTest 实践中最容易踩的坑建议作为 Code Review 时的对照表// ❌ Wrong argument order Assert.AreEqual(actual, expected); // ✅ Correct Assert.AreEqual(expected, actual); // ❌ Using ExpectedException (obsolete) [ExpectedException(typeof(ArgumentException))] // ✅ Use Assert.Throws Assert.ThrowsArgumentException(() Method()); // ❌ Using LINQ Single() - unclear exception var item items.Single(); // ✅ Use ContainsSingle - better failure message var item Assert.ContainsSingle(items); // ❌ Hard cast - unclear exception var handler (MyHandler)result; // ✅ Type assertion - shows actual type on failure var handler Assert.IsInstanceOfTypeMyHandler(result); // ❌ Ignoring cancellation token await client.GetAsync(url, CancellationToken.None); // ✅ Flow test cancellation await client.GetAsync(url, TestContext.CancellationToken); // ❌ Making TestContext nullable - leads to unnecessary null checks public TestContext? TestContext { get; set; } // ❌ Using null! - MSTest already suppresses CS8618 for this property public TestContext TestContext { get; set; } null!; // ✅ Declare without nullable or initializer - MSTest handles the warning public TestContext TestContext { get; set; }逐条解读其中的设计逻辑AreEqual(actual, expected)期望/实际顺序颠倒后失败消息中的Expected/Actual含义会被反转误导排错方向[ExpectedException]已过时无法断言异常细节与发生位置用Assert.Throws系列替代Single()失败时抛出的InvalidOperationException信息含糊Assert.ContainsSingle会给出包含集合内容与期望的失败消息硬转换(MyHandler)result类型不符时抛出难以理解的InvalidCastExceptionAssert.IsInstanceOfType失败时会显示实际类型CancellationToken.None丢弃了 MSTest 提供的取消信号超时/中断时无法协作式取消改用TestContext.CancellationTokenTestContext声明MSTest 已为属性注入抑制 CS8618 警告写成 null!反而留下不必要的空值暗示可空标记则迫使你在所有调用点做无意义判空——正确写法就是朴素声明。十、测试组织与 Mocking10.1 组织与筛选按功能或组件分组测试保持测试代码与生产代码结构对应用[TestCategory(Category)]给测试打分类标签配合dotnet test --filter TestCategoryCategory实现按类别运行如区分 Unit/Integration/Smoke用[TestProperty(Name, Value)]附加自定义元数据例如[TestProperty(Bug, 12345)]将测试与缺陷单号关联用[Priority(1)]标记关键测试数字越小优先级越高便于快速圈定必须通过的核心集启用相关的 MSTest 分析器规则尤其MSTEST0020建议用构造函数替代[TestInitialize]让编译期自动约束团队写法。这与 Skill 中优先构造器的约定前后呼应。10.2 Mocking 与隔离使用Moq 或 NSubstitute模拟依赖通过接口暴露依赖以便模拟面向接口编程是模拟的前提模拟依赖以隔离被测单元让测试只验证目标类的行为而不受外部系统影响。仓库 agents/CSharpExpert.agent.md 对 Mocking 有更进一步的工程约束优先避免 mock外部依赖才可 mock绝不 mock 被测解决方案内部实现并建议为 mock 与被模拟依赖的输出一致性补充测试。这条纪律与隔离被测单元的原则一脉相承可作为团队 Mocking 策略的补充红线。十一、在 Copilot 工作流中使用本指南csharp-mstestSkill 在仓库中的真实使用方式是开发者或 CI 中的 Agent触发该 Skill 后Copilot 会遵循本指南的规范生成/审查测试代码。其落地链路为安装gh skills install github/awesome-copilot csharp-mstest见 docs/README.skills.md通过csharp-dotnet-development插件统一接入多个 C# 技能见 plugins/csharp-dotnet-development/plugin.jsonCopilot 在编写 MSTest 代码时自动应用本文的全部规范构造器初始化、Assert.Throws、ValueTuple 数据源、TestContext.CancellationToken、分析器启用等。由此给 Copilot 下指令与团队测试规范落地被统一到同一份文档中——这正是该 Skill 的设计价值。结语从项目搭建、测试生命周期到三套断言类、两类数据驱动写法再到TestContext取消机制、重试/条件执行/并行化等高级特性这份基于 awesome-copilot 仓库 csharp-mstest Skill 的指南覆盖了 MSTest 3.x/4.x 现代开发的完整知识面。核心要点可归纳为五条测试类 sealed AAA 规范命名、构造器优先于[TestInitialize]、断言一律走现代 APIThrows / ContainsSingle / IsInstanceOfType、数据驱动用 ValueTuple 或 TestDataRow、始终流动TestContext.CancellationToken。把这份规范沉淀进团队与 AI 助手的共享指令你就拥有了可规模化复制的 .NET 单元测试质量基线。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考