使用 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），僅供參考