使用 NUnit 编写高质量单元测试C# 测试结构与数据驱动测试最佳实践awesome-copilot【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilotNUnit 是 .NET 生态中最成熟的单元测试框架之一以其丰富的属性体系Attribute和对数据驱动测试Data-Driven Testing的一流支持著称。本文以 awesome-copilot 仓库中的 csharp-nunit 技能 为骨架系统讲解从测试项目初始化、测试类结构设计、断言风格选择到 Mock 隔离与测试组织的一整套 NUnit 实战规范并辅以仓库源码与插件配置作为佐证。读完本文你将能够独立搭建规范的 NUnit 测试项目写出可维护、可复现、支持参数化的高质量单元测试。该技能在仓库中同时被 testing-automation 插件 与 csharp-dotnet-development 插件 收录可通过/testing-automation:csharp-nunit或/csharp-dotnet-development:csharp-nunit命令在 GitHub Copilot 中直接唤起作为编写 NUnit 测试时的最佳实践参考。项目搭建从零初始化 NUnit 测试工程规范的测试工程是高质量测试的第一步。NUnit 最佳实践对测试项目的组织方式有明确约定核心要点如下独立的测试项目测试代码与被测代码必须分离测试项目命名遵循[ProjectName].Tests约定。例如被测程序集为Calculator则测试项目命名为Calculator.Tests。必要的 NuGet 包引用测试项目至少需要引用三个包——Microsoft.NET.Test.Sdk测试执行宿主、NUnit测试框架本体与NUnit3TestAdapterNUnit 3 与dotnet test的桥接适配器。缺少 TestAdapter 时dotnet test将无法发现或运行 NUnit 测试。测试类与被测类一一对应为每个被测类创建同名测试类例如被测类Calculator对应测试类CalculatorTests保证测试可发现性。统一使用 .NET SDK 命令运行全部测试通过dotnet test运行无需额外测试运行器。以典型命令行为例创建并运行测试项目的流程如下# 创建被测类库与被测类 Calculator dotnet new classlib -n Calculator # 创建测试项目自动引用 NUnit 相关包 dotnet new nunit -n Calculator.Tests # 建立测试项目对类库的引用 dotnet add Calculator.Tests reference Calculator # 运行全部测试 dotnet testdotnet new nunit模板会自动生成[TestFixture]标记的示例测试类并在.csproj中预先加入上述三个包是快速起步的推荐方式。仓库 playwright-dotnet 指令 也从侧面印证了这一生态约定不同测试框架通过各自的包提供宿主与适配器如 NUnit 对应Microsoft.Playwright.NUnit并使用各自的特性标记测试方法。测试结构用特性构建清晰的测试生命周期NUnit 通过一套声明式特性Attribute描述测试的结构与生命周期这是它与 xUnit构造函数 Dispose等框架最大的差异之一。类与方法级特性[TestFixture]标记测试类。在 NUnit 3 中该特性是可选但推荐的显式声明可提高可读性并为后续的参数化、泛型测试做准备。[Test]标记测试方法对应一个可执行、可断言的测试用例。生命周期钩子特性作用域执行时机典型用途[SetUp]每个测试方法每个[Test]执行前运行初始化被测对象、准备数据、重置 Mock 状态[TearDown]每个测试方法每个[Test]执行后运行释放单次测试占用的资源、清理临时文件[OneTimeSetUp]整个测试类类中第一个测试前运行一次建立数据库连接、加载配置、初始化重量级资源[OneTimeTearDown]整个测试类类中最后一个测试后运行一次关闭连接、清理类级资源[SetUpFixture]整个命名空间/程序集程序集级初始化跨测试类共享的环境准备如启动测试服务器从源码结构看见 csharp-nunit/SKILL.mdNUnit 的生命周期模型是每测试方法级 类级 程序集级的三层结构层级越往上执行次数越少、共享范围越大。这与 xUnit 的IClassFixtureT类级共享与ICollectionFixtureT多类共享模型形成对应关系理解这一分层有助于选择正确的资源生命周期。标准测试聚焦单一行为的 AAA 范式编写标准测试时应遵循以下原则它们直接决定测试的可读性与可维护性保持单一行为聚焦一个测试方法只验证一个行为切忌把多个断言目标混在一个测试里——一旦失败将难以定位根因。遵循 Arrange-Act-AssertAAA模式先准备被测对象与输入Arrange再执行被测动作Act最后校验结果Assert三段之间用空行分隔。使用表达意图的清晰断言断言的语义应与行为预期一致而非机械地比较实现细节。只包含验证本用例所需的断言多余断言会增加耦合后续重构时更容易被误伤。测试独立且幂等每个测试不依赖其他测试的执行顺序或残留状态可以以任意顺序、任意次数重复运行。避免测试间相互依赖不得通过前一个测试执行后才能跑的方式传递状态这是测试套件不稳定的头号来源。综合这些规范一个符合标准的测试方法示例如下[TestFixture] public class CalculatorTests { private Calculator _sut; [SetUp] public void SetUp() { _sut new Calculator(); } [Test] public void Add_TwoPositiveNumbers_ReturnsSum() { // Arrange int a 2; int b 3; // Act int result _sut.Add(a, b); // Assert Assert.That(result, Is.EqualTo(5)); } }方法名Add_TwoPositiveNumbers_ReturnsSum遵循方法名_场景_预期行为的命名范式从方法名即可读懂测试意图。数据驱动测试从[TestCase]到[Combinatorial]数据驱动是 NUnit 最强大的能力之一它允许用一份测试逻辑覆盖大量输入组合。技能文档见 csharp-nunit/SKILL.md列出了 7 种核心数据源特性各自的适用场景如下特性数据来源适用场景[TestCase]内联参数少量固定输入直接在特性上声明可附带ExpectedResult[TestCaseSource]编程生成的数据数据量大或来自外部源文件、数据库、工厂方法[Values]参数级取值集合对单个参数枚举若干取值[ValueSource]属性/方法返回的数据源复用的命名数据源[Random]随机数值随机化边界探测、模糊测试[Range]顺序数值区间等差序列输入如[Range(1, 10, 2)]产生 1、3、5、7、9[Combinatorial]/[Pairwise]多参数组合自动组合多个参数的取值Pairwise 以更少用例覆盖两两组合内联数据[TestCase][TestCase]是最高频的写法每个特性实例生成一个测试用例并可声明期望结果[TestCase(2, 3, 5)] [TestCase(-1, 1, 0)] [TestCase(int.MaxValue, 0, int.MaxValue)] public void Add_VariousInputs_ReturnsExpected(int a, int b, int expected) { int result _sut.Add(a, b); Assert.That(result, Is.EqualTo(expected)); }支持ExpectedResult返回风格时还可以配合[TestCase]写成更紧凑的校验形式。编程生成数据[TestCaseSource]当数据需要动态生成例如从配置文件或工厂读取时使用[TestCaseSource]指向一个静态方法或属性private static IEnumerableTestCaseData AdditionCases() { yield return new TestCaseData(2, 3).Returns(5).SetName(2 plus 3 equals 5); yield return new TestCaseData(-1, 1).Returns(0).SetName(negative plus positive equals zero); } [TestCaseSource(nameof(AdditionCases))] public int Add_FromSource_ReturnsExpected(int a, int b) { return _sut.Add(a, b); }TestCaseData还支持SetCategory、SetDescription、Explicit等元数据方法让动态生成的用例也能拥有丰富的元信息。参数级数据与组合当方法有多个参数时可用[Values]、[Range]描述每个参数的取值集合再用[Combinatorial]或[Pairwise]控制组合策略[Test] [Combinatorial] public void Multiply_WithCombinatorialValues( [Values(1, 2, 3)] int a, [Range(2, 4, 2)] int b) { // 1x2、1x4、2x2、2x4、3x2、3x4 共 6 个组合 Assert.That(_sut.Multiply(a, b), Is.GreaterThanOrEqualTo(2)); }需要注意的是[Combinatorial]生成笛卡尔积参数多时用例数会爆炸[Pairwise]只保证任意两参数组合被覆盖大幅削减用例数更适合参数较多的场景。断言体系约束模型Constraint Model优先NUnit 提供两代断言风格技能文档明确建议优先使用约束模型见 csharp-nunit/SKILL.md约束模型推荐Assert.That(actual, constraint)约束对象以Is.、Contains.、Does.等静态类开头的 DSL 组合表达可读性极强且支持链式组合。经典模型Assert.AreEqual、Assert.IsTrue等老式方法语法简单但表达能力弱主要用于兼容遗留代码。常用约束速查目标约束模型写法经典模型写法值相等Assert.That(x, Is.EqualTo(5))Assert.AreEqual(5, x)引用同一实例Assert.That(x, Is.SameAs(obj))Assert.AreSame(obj, x)集合包含Assert.That(list, Contains.Item(a))CollectionAssert.Contains(list, a)异常抛出Assert.ThrowsArgumentException(() sut.Parse(null))—异步异常Assert.ThrowsAsyncTimeoutException(() sut.RunAsync())—断言的两大注意点异常测试使用Assert.ThrowsT捕获同步异常、Assert.ThrowsAsyncT捕获异步异常返回的异常实例可进一步断言其Message、ParamName等属性。描述性消息在断言中附带说明性消息例如Assert.That(result, Is.EqualTo(expected), 序列化后的金额应与源数据一致)失败时能立即看出上下文避免大海捞针。集合比较优先用CollectionAssertAreEqual、IsSubsetOf、AllItemsAreInstancesOfType等字符串专属校验用StringAssertStartsWith、Contains、Matches等。Mocking 与隔离让单元测试名副其实单元测试的目标是隔离被测单元因此对协作者数据库、HTTP 客户端、文件系统等的替身管理至关重要。技能文档给出的建议见 csharp-nunit/SKILL.md包括引入 Mock 库Moq 与 NSubstitute 是 NUnit 生态中最常用的搭档二者 API 风格不同Moq 偏向Setup/VerifyNSubstitute 偏向替换后的对象即替身可依据团队偏好选择。Mock 依赖以隔离被测单元所有外部协作者都应被替换为可控的替身测试中只驱动真实的被测代码。面向接口设计被测类的依赖以接口形式注入构造函数注入这是可 Mock 性的前提。若被测类直接new具体类或使用静态调用将无法隔离。复杂装配使用 DI 容器当被测对象依赖树较深时可在测试工程中引入 DI 容器如 Microsoft.Extensions.DependencyInjection在[SetUp]中注册真实实现 Mock 依赖在[OneTimeSetUp]/[SetUpFixture]中管理重量级共享实例。Moq NUnit 的典型组合示例如下[TestFixture] public class OrderServiceTests { private MockIPaymentGateway _paymentGateway; private OrderService _sut; [SetUp] public void SetUp() { _paymentGateway new MockIPaymentGateway(); _sut new OrderService(_paymentGateway.Object); } [Test] public void PlaceOrder_ValidOrder_CallsPaymentGatewayOnce() { _paymentGateway .Setup(g g.ChargeAsync(It.IsAnydecimal())) .ReturnsAsync(true); var orderId _sut.PlaceOrder(amount: 99.9m).Result; _paymentGateway.Verify(g g.ChargeAsync(99.9m), Times.Once); Assert.That(orderId, Is.Not.Null); } }测试组织分类、排序与元数据测试规模变大后组织策略决定维护成本。技能文档给出了完整的组织工具箱见 csharp-nunit/SKILL.md按功能或组件分组把同属一个特性/模块的测试放在同一测试类或命名空间目录结构与被测模块对齐。[Category(CategoryName)]打上逻辑分类标签如Unit、Integration、Slow配合dotnet test --filter CategoryUnit可按类别选择性运行。[Order(N)]必要时控制执行顺序如渐进式状态流转测试但需牢记顺序依赖是反模式仅在确有需要时使用。[Author(DeveloperName)]标注测试作者便于追溯责任。[Description(...)]为测试补充说明供测试报告与 IDE 展示。[Explicit]标记后测试默认不运行必须在运行器或 CI 中显式勾选/指定才会执行适合手工验证型或性能型测试。[Ignore(Reason)]临时跳过失败的测试务必附上跳过原因与恢复计划避免永远忽略。组合使用示例[TestFixture] [Category(Unit)] public class PriceCalculatorTests { [Test] [Category(Boundary)] [Author(Alice)] [Description(验证价格为 0 时抛出业务异常)] [Order(1)] public void Calculate_ZeroPrice_ThrowsBusinessException() { Assert.ThrowsBusinessException(() _sut.Calculate(0)); } [Test] [Category(Boundary)] [Ignore(等待 BUG-1234 修复后恢复)] [Order(2)] public void Calculate_NegativePrice_ReturnsZero() { // 临时跳过的用例 } [Test] [Explicit] public void FullRegression_ManualRunOnly() { // 仅在显式指定时运行 } }对应到命令行# 只运行 Unit 分类 dotnet test --filter CategoryUnit # 只运行 Boundary 分类 dotnet test --filter CategoryBoundary # 按名称模糊过滤 dotnet test --filter FullyQualifiedName~PriceCalculator技能在仓库中的定位与使用方式本技能文档skills/csharp-nunit/SKILL.md是 awesome-copilot 社区贡献的 Copilot 技能之一其 frontmatter 中的description字段——Get best practices for NUnit unit testing, including contenteditable="false">【免费下载链接】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），仅供参考