没有项目正文说实话这反而给了不少发挥空间。做技术分享这么多年每次拿到“全功能项目”这个词我心里都有数——这往往是团队里准备立标杆、做模板的信号不单纯是几个人写几段测试那么简单。这篇我就拿【实战项目6】nUnit框架全功能项目当作实战样板聊聊我实际搭建这套测试体系时踩过的坑、做过的取舍以及那张架构图到底该怎么画才不糊弄人。先给没接触过nUnit的朋友交个底nUnit是.NET生态里最老牌的单元测试框架之一出身于极限编程社区和JUnit同源后来在.NET Core时代全面重写目前的nUnit 3.x支持异步测试、数据驱动、并行执行、跨平台运行生态成熟度非常高。项目标题里加上了“全功能”和“架构图”说明要的不只是“会写断言”而是一套能支撑接口测试、业务逻辑测试、数据驱动、测试隔离、CI集成的完整工程。如果你是刚接手中型.NET项目、想把测试体系从“零散脚本”升级成“正规军”或者正在评估测试框架选型这篇文章就是为你准备的。1. 项目整体设计与架构思路1.1 为什么要用一个重型框架来组织测试很多团队写单元测试都是新建一个测试项目然后按照“被测类名 Tests”的方式堆测试类一个类写几十个方法方法里直接new依赖、连接数据库、发请求。前期跑得飞快等到项目规模上来问题就集中爆发了测试之间互相干扰数据库状态一脏全部红跑一次测试几分钟起步没人愿意再碰这套测试。用nUnit这类框架的意义不光是提供Assert断言方法更重要的是它在框架层面帮你强制建立一套约定生命周期由SetUp/TearDown管理、数据由TestCase/TestCaseSource驱动、执行策略由特性控制、分层由Fixture划分。标题里提到的“架构图”我理解不是画一张炫酷的部署图而是把一个测试工程的结构、依赖关系、执行顺序、隔离策略可视化成一张“地图”。这张地图的价值在于任何新成员进入项目后能快速回答三个问题这条测试用例在测什么依赖了哪些外部资源如果跑挂了我应该从哪个环节排查1.2 方案选型为什么是nUnit而不是xUnit或MSTest我见过很多团队在nUnit和新贵xUnit之间纠结做技术选型时也从众选了xUnit理由是“新项目用新框架”。但我这几年实际用下来nUnit在大型业务项目里反而表现更稳原因有三个第一参数化数据驱动的表达力更强。nUnit的TestCase、TestCaseSource、ValueSource组合非常灵活一个测试方法可以挂几百组数据配合TestCaseData的SetName、ExpectedResult、Category报表里能直接看出每条用例的业务含义。xUnit也有MemberData/InlineData但动态生成测试名、按业务维度组织用例nUnit更顺手。第二测试隔离和生命周期控制更直观。OneTimeSetUp、SetUp、OneTimeTearDown、TearDown这四个层级的设计非常清晰。OneTimeSetUp适合准备整个Fixture共享的资源SetUp适合每个用例前重置状态。xUnit里用IClassFixture、ICollectionFixture概念也能做到但心智负担明显更高新手上手慢。第三并行执行的成熟度。nUnit 3的LevelOfParallelism和NonParallelizable加PartialScope可以在类级别、方法级别精准控制并发。做集成测试时有些资源不能并发访问但有些可以这种细粒度控制在真实项目中极其重要。当然我不是踩xUnit它设计得更现代、更符合依赖注入的Style如果你的团队全用ASP.NET Core的DI模式xUnit也不错。但“全功能项目”这个定位我更推荐nUnit。1.3 架构图的核心分层理念在开始动手写代码前我花了一整晚把架构图导出来分成了四层用例表达层存放所有Fixture测试类只负责“描述业务场景与断言结果”不关心数据从哪来、资源如何初始化。数据驱动层存放TestCaseSource数据源、TestData工厂、Json/Yaml读取器集中管理所有测试数据。基础设施层封装数据库连接、HttpClient、文件操作、时间服务等外部依赖的访问入口提供可控的测试替身。执行编排层通过AssemblyInfo配置全局执行策略、并行度、Category过滤规则控制测试的运行方式和CI中的分组。这四层不是按目录硬拆的而是按“依赖方向”划分的用例表达层依赖数据驱动层和基础设施层基础设施层不依赖任何测试用例执行编排层是全局横切关注点不参与业务逻辑。这张图我贴在项目Wiki的首屏后来Code Review时发现绝大多数新人看一眼就知道自己的代码该放哪测试新增效率至少提升一倍。2. 环境准备与项目结构搭建2.1 创建测试项目的正确姿势以.NET 8为例假设解决方案根目录下已有被测项目MyApp.Business新建测试项目的命令如下dotnet new nunit -n MyApp.Business.Tests dotnet add MyApp.Business.Tests reference MyApp.Business cd MyApp.Business.Tests dotnet add package Microsoft.NET.Test.Sdk dotnet add package NUnit3TestAdapter dotnet add package coverlet.collector这里的三个包缺一不可Microsoft.NET.Test.Sdk是测试宿主NUnit3TestAdapter是Visual Studio/命令行测试发现器与nUnit之间的桥coverlet.collector用于收集覆盖率数据。有个新手经常踩的坑只看教程安装了NUnit和NUnit3TestAdapter忘了装Microsoft.NET.Test.Sdk结果dotnet test跑不起来或者说测试发现不了。另外注意.NET Core时代不要装NUnit2TestAdapter那是给.NET Framework老项目用的混装会导致诡异的双适配器冲突。2.2 项目目录结构的标准化设计我强烈建议测试项目内部也做分层不要把所有测试类平铺在根目录。我的标准结构是这样MyApp.Business.Tests/ ├─ AssemblyInfo.cs ├─ Fixtures/ │ ├─ OrderServiceTests.cs │ ├─ PaymentServiceTests.cs │ └─ InvoiceGeneratorTests.cs ├─ Data/ │ ├─ OrderTestData.cs │ ├─ PaymentTestCases.cs │ └─ JsonData/ │ ├─ orders.json │ └─ payment.invalid.json ├─ Infrastructure/ │ ├─ TestDatabase.cs │ ├─ MockHttpServer.cs │ └─ FakeTimeProvider.cs ├─ Utilities/ │ ├─ RandomDataGenerator.cs │ └─ AssertExtensions.cs └─ Integration/ ├─ OrderFlowIntegrationTests.cs └─ PaymentRetryIntegrationTests.csFixtures下放单元测试Integration下放跨模块集成测试Data集中管理数据源Infrastructure放测试基础设施。注意这里有一个关键约定避免在单位测试目录里偷偷访问数据库如果某个测试需要连数据库就放到Integration目录并打上[Category(Integration)]标签。这个约定靠人自觉不好维持我后来在CI脚本里加了强制过滤只跑Unit类别从机制上把两类测试分开。2.3 AssemblyInfo全局配置的细节nUnit 3把全局配置放在AssemblyInfo.cs在nUnit项目中加了这些内容using NUnit.Framework; [assembly: LevelOfParallelism(4)] [assembly: Parallelizable(ParallelScope.Fixtures)] [assembly: NonParallelizable]这里要注意NonParallelizable和Parallelizable同时存在时的优先级容易让人困惑。简单说Fixture方法上的特性优先级最高然后依次是Fixture类、程序集越具体越优先。所以我习惯的做法是程序集层面全局开启Fixtures级别的并行关闭方法级别并行再在个别需要并行的Fixture类上用Parallelizable(ParallelScope.Self)覆盖。并行执行不是免费的如果两个Fixture共享同一个静态类或数据库分分钟出偶发失败。我第一次开并行时测试速度提了4倍但随机红了一批用例排查半天发现是共享的静态Mock。所以开并行之前先保证每一个Fixture的资源完全隔离。3. 核心功能实现与封装细节3.1 生命周期方法的选择策略nUnit的生命周期方法看起来简单但用对了才能减少大量重复代码。我的选择策略一条条说清楚[OneTimeSetUp]整个Fixture运行前执行一次适合数据库迁移、启动Mock HTTP Server、准备大文件等重量级操作。注意它跟[SetUp]的区别很多人都栽在这里——[SetUp]是每个测试方法执行前都会调一次[OneTimeSetUp]只调一次。[TearDown]每个测试方法跑完后执行适合清理当前用例产生的临时文件、重置静态变量、删除测试数据。[OneTimeTearDown]整个Fixture结束后执行适合释放数据库连接、停掉HTTP Server。举个例子测试OrderService时需要内存数据库如果每次SetUp都new一个性能极差但如果全部用例共用一个数据库又可能出现用例间数据污染。我的折中方案是OneTimeSetUp里初始化数据库结构并开启事务SetUp里开一个新事务TearDown里回滚事务这样每个用例看到的是干净快照性能还高。3.2 数据驱动的三种玩法nUnit的数据驱动是它最强的地方之一我按复杂度从低到高列一下最基础的[TestCase]适合固定几组小数据。[TestCase(1, 2, 3)] [TestCase(10, 20, 30)] [TestCase(0, 0, 0)] public void Add_ShouldReturnExpectedSum(int a, int b, int expected) { var result Calculator.Add(a, b); Assert.That(result, Is.EqualTo(expected)); }进阶的[TestCaseSource]适合从静态类、外部文件、数据库读取的大批量数据。数据源必须是静态方法或静态属性且参数和返回值必须匹配。public static IEnumerableTestCaseData InvalidOrderData() { yield return new TestCaseData(null, 订单号不能为空); yield return new TestCaseData(, 订单号不能为空); yield return new TestCaseData(ABC, 订单号格式不正确); } [TestCaseSource(nameof(InvalidOrderData))] public void Validate_ShouldReturnErrorMessage(string orderNo, string expectedMessage) { var result OrderValidator.Validate(orderNo); Assert.That(result, Does.Contain(expectedMessage)); }重量级玩法[TestCaseData SetName Category]当用例达到几十上百条时默认显示的名字根本分不清业务含义此时用SetName给用例设置中文别名或业务名报表瞬间直观。public static IEnumerableTestCaseData PaymentScenarios() { yield return new TestCaseData(100m, CNY, 100m) .SetName(等额支付-人民币-全额) .SetCategory(Payment); yield return new TestCaseData(100m, USD, 715.32m) .SetName(跨币种支付-美元-按汇率折算) .SetCategory(Payment); }实际项目里我还会用TestCaseData的Explicit属性控制某些用例只在手动点击时执行以及用Ignore属性临时跳过失败的已知bug用例。但注意Ignore不能成为常态我要求团队任何用例Ignore时间不超过一个迭代否则一律删除重建。3.3 断言该用经典模式还是约束模式nUnit 3里断言有两种写法经典模式Assert.AreEqual和约束模式Assert.That(actual, Is.EqualTo(expected))新项目我强推约束模式。原因不只是美观而是约束模式的失败信息详细得多。比如字符串包含失败经典模式只告诉你“Expected: contains x, But was: y”约束模式还能显示实际字符串中哪个位置不匹配、索引是多少排查效率天差地别。再补充一些用得最多的约束值得收藏数值断言Is.EqualTo(3.14).Within(0.01)浮点比较必备不然你永远不知道为什么算出来的结果对不上。集合断言Does.Contain、Is.EquivalentTo忽略顺序的相等、Is.Unique、Is.Ordered在测试List去重和排序的时候省太多事了。异常断言不要用try/catch包起来再Assert.Fail直接Assert.That(() service.Pay(null), Throws.TypeOfArgumentException().With.Message.Contains(订单号))。异步断言nUnit 3原生支持async Task测试方法可直接用Assert.That(async () await service.GetAsync(1), Is.Not.Null)。3.4 测试替身的正确使用边界全功能测试项目一定会涉及Mock比如Moq、NSubstitute。但很多人误以为测试替身就是“无脑Mock一切”。我的原则是Mock外部依赖HttpClient、数据库仓库接口、文件系统接口这些必须Mock保证单元测试不依赖真实网络和环境。Mock边界服务发送邮件、短信、调用第三方支付这类服务Mock后要有明确的验证断言验证“调用过且参数正确”。不要Mock自己写的业务类如果测试OrderService时Mock掉OrderValidator那这个测试基本是在自欺欺人验证的是Mock库有没有按配置返回而不是业务逻辑。在项目里我用NSubstitute搭配nUnit比较多因为NSubstitute的语法更简洁Received(1)表示调用次数断言感觉比Moq的Verify顺眼。NSubstitute有个隐藏坑如果方法返回Task用sub.FindAsync(1)需要小心必须直接return Task.FromResult或使用ReceivedWithAnyArgs否则可能拿不到预期的纤程调度结果。4. 架构图绘制要点与执行策略设计4.1 架构图应该画到什么粒度项目标题里特意带上了“架构图”我推测是要向团队展示设计能力。测试项目的架构图切忌画成一个大圆环包一堆方块那是给老板看的“心理安慰图”。真正有用的架构图应该画到“类”与“接口”这一层至少要让读者看到每个Fixture依赖哪个基础设施。我画图的成品长下面这样不是mermaid就是最朴素的方块箭头------------------------------------------- | 执行编排层 (AssemblyInfo) | | LevelOfParallelism / CategoryFilter | ------------------------------------------- | | v v ------------------- ------------------- | 用例表达层 | | 数据驱动层 | | OrderTests |→| OrderTestData | | PaymentTests |→| PaymentCases | | InvoiceTests | | JsonDataLoader | ------------------- ------------------- | | v v ------------------- ------------------- | 基础设施层 | | 基础设施层(替身) | | TestDatabase | | MockHttpServer | | RealHttpClient | | FakeTimeProvider | ------------------- ------------------- | | --------------- v ------------------ | 被测系统边界 | | MyApp.Repository| | MyApp.Business | ------------------这张图的要点是画出了依赖方向一眼就能判断哪些测试依赖真实基础设施、哪些依赖替身。执行编排层虽然是全局配置但箭头画成松散虚线表示它更多是“策略”而不是“组件被依赖”。4.2 Category分组策略与CI流水线全功能测试项目必然要区分测试层级。我的做法是定义一套Category规范Category标签用途典型执行时机Unit纯内存单元测试每次pushIntegration依赖数据库、文件系统PR验证/每日构建Smoke关键路径冒烟测试发布前Slow耗时超过5秒的用例夜间全量构建CI脚本里对应着跑法# 只跑单元测试快、稳、反馈及时 dotnet test MyApp.Business.Tests --filter TestCategoryUnit --logger trx;LogFileNameunit.trx # PR验证时跑集成测试但跳过慢用例 dotnet test MyApp.Business.Tests --filter TestCategoryIntegrationTestCategory!Slow # 发布前全量 dotnet test MyApp.Business.Tests --filter TestCategorySmoke这里有一个很实用的变量--filter语法里的表示AND|表示OR!表示排除。nUnit的Category过滤规则有多种写法如果不小心把TestCategory拼成Category测试会全部被过滤掉也就是跑0个用例且“成功”退出这种假绿比真红更可怕。4.3 并行执行实战调优关于并行我再分享一组实测数据。一个拥有320个单元测试用例的项目单线程跑要100秒开启程序集级别的LevelOfParallelism(4)后时间降到35秒但此时同步静态依赖的用例开始偶发失败。我的最终方案是90%的Fixture用ParallelScope.Fixtures并行共享统一数据库的Fixture打上[NonParallelizable]强制串行每个Fixture内部的方法级默认串行只有纯函数、无状态的测试方法所在的类再显式开方法级并行。另外在输出日志时一定要带上TestContext.CurrentContext.Test.Name并行时日志乱序是常态没有用例名做前缀排查问题简直地狱难度。5. 实操过程从零到一构建一个完整测试项目5.1 搭建被测系统模拟环境为了让读者能完整复现我设计了一个迷你业务场景一个OrderService负责生成订单、校验库存、计算应付金额、支持跨境支付汇率换算。被测项目结构很简单public interface IProductRepository { TaskProduct GetByIdAsync(int id); Taskbool DeductStockAsync(int productId, int quantity); } public interface IPaymentGateway { TaskPaymentResult ChargeAsync(decimal amount, string currency); } public class OrderService { private readonly IProductRepository _productRepository; private readonly IPaymentGateway _paymentGateway; public OrderService(IProductRepository productRepository, IPaymentGateway paymentGateway) { _productRepository productRepository; _paymentGateway paymentGateway; } public async TaskOrder CreateOrderAsync(int productId, int quantity, string currency) { var product await _productRepository.GetByIdAsync(productId); if (product null) throw new ArgumentException(商品不存在, nameof(productId)); if (product.Stock quantity) throw new InvalidOperationException(库存不足); var amount product.Price * quantity; var paymentResult await _paymentGateway.ChargeAsync(amount, currency); if (!paymentResult.Success) throw new InvalidOperationException($支付失败: {paymentResult.ErrorMessage}); return new Order { Id Guid.NewGuid(), ProductId productId, Quantity quantity, TotalAmount amount, Currency currency, Status OrderStatus.Paid, PaymentReference paymentResult.Reference }; } }5.2 为OrderService编写完整的nUnit测试现在写一个符合“全功能”标准的测试类覆盖正常路径、业务异常、边界数据、Mock验证using NUnit.Framework; using NSubstitute; namespace MyApp.Business.Tests.Fixtures; [TestFixture] [Category(Unit)] public class OrderServiceTests { private IProductRepository _productRepository; private IPaymentGateway _paymentGateway; private OrderService _orderService; [SetUp] public void SetUp() { _productRepository Substitute.ForIProductRepository(); _paymentGateway Substitute.ForIPaymentGateway(); _orderService new OrderService(_productRepository, _paymentGateway); } [Test] public async Task CreateOrderAsync_WithValidInput_ShouldReturnPaidOrder() { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 10 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); _paymentGateway.ChargeAsync(200m, CNY) .Returns(Task.FromResult(new PaymentResult { Success true, Reference P001 })); var order await _orderService.CreateOrderAsync(1, 2, CNY); Assert.That(order.Status, Is.EqualTo(OrderStatus.Paid)); Assert.That(order.TotalAmount, Is.EqualTo(200m)); Assert.That(order.PaymentReference, Is.EqualTo(P001)); await _productRepository.Received(1).DeductStockAsync(1, 2); await _paymentGateway.Received(1).ChargeAsync(200m, CNY); } [Test] public void CreateOrderAsync_WhenProductNotExist_ShouldThrowArgumentException() { _productRepository.GetByIdAsync(999).Returns(Task.FromResultProduct(null)); var ex Assert.ThrowsAsyncArgumentException( () _orderService.CreateOrderAsync(999, 1, CNY)); Assert.That(ex.ParamName, Is.EqualTo(productId)); Assert.That(ex.Message, Does.Contain(商品不存在)); } [TestCase(0)] [TestCase(-1)] [TestCase(int.MinValue)] public void CreateOrderAsync_WhenQuantityIsInvalid_ShouldThrowArgumentOutOfRangeException(int quantity) { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 100 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); Assert.ThrowsAsyncArgumentOutOfRangeException( () _orderService.CreateOrderAsync(1, quantity, CNY)); } [Test] public void CreateOrderAsync_WhenStockNotEnough_ShouldThrowInvalidOperationException() { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 5 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); var ex Assert.ThrowsAsyncInvalidOperationException( () _orderService.CreateOrderAsync(1, 10, CNY)); Assert.That(ex.Message, Does.Contain(库存不足)); await _productRepository.Received(0).DeductStockAsync(Arg.Anyint(), Arg.Anyint()); } [Test] public void CreateOrderAsync_WhenPaymentFails_ShouldThrowAndNotCreateOrder() { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 10 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); _paymentGateway.ChargeAsync(100m, CNY) .Returns(Task.FromResult(new PaymentResult { Success false, ErrorMessage 余额不足 })); var ex Assert.ThrowsAsyncInvalidOperationException( () _orderService.CreateOrderAsync(1, 1, CNY)); Assert.That(ex.Message, Does.Contain(余额不足)); await _productRepository.Received(1).DeductStockAsync(1, 1); } }注意几个细节[TestFixture]在nUnit 3中可以省略但我习惯保留提示读者这是个Fixture类Received(0)表示验证从未调用这个在防止“绕过关键逻辑”时非常有用Assert.ThrowsAsync返回异常对象可以继续断言异常参数名和消息比只写一行Assert.Throws信息量大得多。5.3 数据驱动测试进阶从Json读取测试用例当业务规则复杂时TestCase写在代码里会越来越臃肿。我通常会把场景数据迁移到Json文件中资源文件标记为CopyToOutputDirectory[ { productId: 1, quantity: 2, currency: USD, expectedAmount: 1430.64, expectedCurrency: USD }, { productId: 2, quantity: 3, currency: EUR, expectedAmount: 1075.47, expectedCurrency: EUR } ]搭配一个静态数据源类public static class OrderTestData { public static IEnumerableTestCaseData FromJson() { var jsonPath Path.Combine(TestContext.CurrentContext.TestDirectory, Data, order_cases.json); var rows JsonSerializer.DeserializeListOrderTestCase(File.ReadAllText(jsonPath)); foreach (var row in rows) { yield return new TestCaseData( row.ProductId, row.Quantity, row.Currency, row.ExpectedAmount) .SetName($订单-商品{row.ProductId}-数量{row.Quantity}-币种{row.Currency}) .SetCategory(DataDriven); } } }测试方法只需一条[TestCaseSource][TestCaseSource(typeof(OrderTestData), nameof(OrderTestData.FromJson))] public async Task CreateOrderAsync_WithExternalData_ShouldCalculateCorrectAmount( int productId, int quantity, string currency, decimal expectedAmount) { var product new Product { Id productId, Name 商品, Price 100m, Stock 100 }; _productRepository.GetByIdAsync(productId).Returns(Task.FromResult(product)); _paymentGateway.ChargeAsync(expectedAmount, currency) .Returns(Task.FromResult(new PaymentResult { Success true, Reference T001 })); var order await _orderService.CreateOrderAsync(productId, quantity, currency); Assert.That(order.TotalAmount, Is.EqualTo(expectedAmount)); }一定要用TestContext.CurrentContext.TestDirectory来定位资源文件不要用Environment.CurrentDirectory。dotnet test执行时的工作目录不是项目目录我在这个坑上浪费了整整一个下午导致CI全部找不到Json文件。5.4 集成测试与数据库事务隔离集成测试比单元测试复杂在外部依赖。以数据库为例我不会直接用生产库而是在OneTimeSetUp里创建内存SQLite数据库并执行迁移脚本在SetUp里开启事务TearDown里回滚。这样测试时无需清表用例之间互不干扰且速度远快于真实数据库。[TestFixture] [Category(Integration)] public class OrderFlowIntegrationTests { private SQLiteConnection _connection; private DataContext _dataContext; [OneTimeSetUp] public void OneTimeSetUp() { _connection new SQLiteConnection(Data Source:memory:); _connection.Open(); _dataContext new DataContext(_connection); _dataContext.Database.EnsureCreated(); } [SetUp] public void SetUp() { _transaction _connection.BeginTransaction(); } [TearDown] public void TearDown() { _transaction.Rollback(); } [OneTimeTearDown] public void OneTimeTearDown() { _connection.Dispose(); } }SQLite内存库的:memory:连接只要关闭连接数据全部消失所以必须保持连接开启而每个事务回滚后所有已执行的Insert/Update都会撤销这在测试数据造数和清理方面是神兵利器。真实业务系统如果用SQL Server可以换成本地容器里的SQL Server镜像但代价是速度慢不少。6. 常见问题与排查技巧实录6.1 测试发现不了或执行报错最常见的问题是“我写了测试方法为什么dotnet test一个case都不跑”优先级排查如下检查测试类是否标注了[TestFixture]nUnit 3虽然可以自动识别但在某些项目配置下漏标会不发现测试方法是不是public且返回void或Task如果不是nUnit不会执行确认项目引用了Microsoft.NET.Test.Sdk和NUnit3TestAdapter用dotnet test --list-tests列出所有测试如果这里没显示说明测试发现阶段就有问题别急着改成测试内容如果是类库而不是测试项目无法执行需要dotnet new nunit重新生成项目模板。6.2 用例跑挂但不知道是哪个步骤出的问题并行开着的时候日志全乱。我的解决办法是三步先关并行AssemblyInfo.cs里把LevelOfParallelism改成1在测试方法里打日志时加TestContext.Progress.WriteLine而不是Console.WriteLine因为nUnit默认会捕获Console输出可以在测试结果附件里查看利用TestContext.CurrentContext.Test.FullNameLogger里把这个打到每行日志最前面排序后用grep过滤单个用例日志。6.3 偶发失败与“测试污染”偶发失败九成是共享状态污染。用这个排查顺序检查静态字段有没有被某个用例修改且没有还原检查是否所有外设Mock都在SetUp里重新创建而不是放在OneTimeSetUp里检查数据库测试是否用了共享事务每用例回滚检查并行Fixture是否操作了相同文件如果有给文件路径按TestContext.CurrentContext.Test.ID加上独立后缀。6.4 覆盖率的正确追求方式覆盖率不是越高越好这是我做了十年测试架构最深刻的体会之一。nUnit配合coverlet统计很方便dotnet test MyApp.Business.Tests --collect:XPlat Code Coverage然后生成报告dotnet tool install -g dotnet-reportgenerator-globaltool reportgenerator -reports:TestResults/**/coverage.cobertura.xml -targetdir:coveragereport -reporttypes:Html我的经验是核心业务模块的单元测试覆盖率争取85%以上基础设施层比如HttpClient封装、数据库仓储可以低一些但关键分支要有测试兜底。不要为了数字好看去写一堆断言空的垃圾测试那是自欺欺人CI里甚至可以在平台层面限制覆盖率低于阈值视为失败。7. 经验心得与工程化建议整套nUnit全功能项目做下来有几条体会越来越深。一是测试代码和业务代码一样需要评审它是有读者、有维护成本的资产不是随手扔掉的草稿纸二是数据驱动和分层隔离是测试工程的两条主线能解决真实的维护痛点三是架构图不只是一张图它承载的是一种约定画出来之后要有人遵守、有人维护否则三个月后就成了一堆摆设。拿这个项目来说我最后还把架构图对应的目录结构同步到了实体项目的Wiki里在Doc中写清楚每个目录应该放什么、禁止放什么新人入职第一天看着图就能动手写测试。这种工程化收益远比单个测试代码写的多来得重要。如果你正准备在自己的团队推行这套方案我建议你先从小范围试点开始挑一个核心业务模块按文中这几步把测试工程搭起来跑上两个迭代再决定是否推广。测试框架本身没有那么多玄学真正拉开差距的还是工程规范和团队共识。最后再分享一个小技巧每次跑完完整测试套件养成看失败截图和日志文件的习惯哪怕全绿也要扫一眼警告信息很多隐藏的地雷都是这时候被揪出来的。
nUnit全功能测试项目实战：架构设计、数据驱动与并行执行
没有项目正文说实话这反而给了不少发挥空间。做技术分享这么多年每次拿到“全功能项目”这个词我心里都有数——这往往是团队里准备立标杆、做模板的信号不单纯是几个人写几段测试那么简单。这篇我就拿【实战项目6】nUnit框架全功能项目当作实战样板聊聊我实际搭建这套测试体系时踩过的坑、做过的取舍以及那张架构图到底该怎么画才不糊弄人。先给没接触过nUnit的朋友交个底nUnit是.NET生态里最老牌的单元测试框架之一出身于极限编程社区和JUnit同源后来在.NET Core时代全面重写目前的nUnit 3.x支持异步测试、数据驱动、并行执行、跨平台运行生态成熟度非常高。项目标题里加上了“全功能”和“架构图”说明要的不只是“会写断言”而是一套能支撑接口测试、业务逻辑测试、数据驱动、测试隔离、CI集成的完整工程。如果你是刚接手中型.NET项目、想把测试体系从“零散脚本”升级成“正规军”或者正在评估测试框架选型这篇文章就是为你准备的。1. 项目整体设计与架构思路1.1 为什么要用一个重型框架来组织测试很多团队写单元测试都是新建一个测试项目然后按照“被测类名 Tests”的方式堆测试类一个类写几十个方法方法里直接new依赖、连接数据库、发请求。前期跑得飞快等到项目规模上来问题就集中爆发了测试之间互相干扰数据库状态一脏全部红跑一次测试几分钟起步没人愿意再碰这套测试。用nUnit这类框架的意义不光是提供Assert断言方法更重要的是它在框架层面帮你强制建立一套约定生命周期由SetUp/TearDown管理、数据由TestCase/TestCaseSource驱动、执行策略由特性控制、分层由Fixture划分。标题里提到的“架构图”我理解不是画一张炫酷的部署图而是把一个测试工程的结构、依赖关系、执行顺序、隔离策略可视化成一张“地图”。这张地图的价值在于任何新成员进入项目后能快速回答三个问题这条测试用例在测什么依赖了哪些外部资源如果跑挂了我应该从哪个环节排查1.2 方案选型为什么是nUnit而不是xUnit或MSTest我见过很多团队在nUnit和新贵xUnit之间纠结做技术选型时也从众选了xUnit理由是“新项目用新框架”。但我这几年实际用下来nUnit在大型业务项目里反而表现更稳原因有三个第一参数化数据驱动的表达力更强。nUnit的TestCase、TestCaseSource、ValueSource组合非常灵活一个测试方法可以挂几百组数据配合TestCaseData的SetName、ExpectedResult、Category报表里能直接看出每条用例的业务含义。xUnit也有MemberData/InlineData但动态生成测试名、按业务维度组织用例nUnit更顺手。第二测试隔离和生命周期控制更直观。OneTimeSetUp、SetUp、OneTimeTearDown、TearDown这四个层级的设计非常清晰。OneTimeSetUp适合准备整个Fixture共享的资源SetUp适合每个用例前重置状态。xUnit里用IClassFixture、ICollectionFixture概念也能做到但心智负担明显更高新手上手慢。第三并行执行的成熟度。nUnit 3的LevelOfParallelism和NonParallelizable加PartialScope可以在类级别、方法级别精准控制并发。做集成测试时有些资源不能并发访问但有些可以这种细粒度控制在真实项目中极其重要。当然我不是踩xUnit它设计得更现代、更符合依赖注入的Style如果你的团队全用ASP.NET Core的DI模式xUnit也不错。但“全功能项目”这个定位我更推荐nUnit。1.3 架构图的核心分层理念在开始动手写代码前我花了一整晚把架构图导出来分成了四层用例表达层存放所有Fixture测试类只负责“描述业务场景与断言结果”不关心数据从哪来、资源如何初始化。数据驱动层存放TestCaseSource数据源、TestData工厂、Json/Yaml读取器集中管理所有测试数据。基础设施层封装数据库连接、HttpClient、文件操作、时间服务等外部依赖的访问入口提供可控的测试替身。执行编排层通过AssemblyInfo配置全局执行策略、并行度、Category过滤规则控制测试的运行方式和CI中的分组。这四层不是按目录硬拆的而是按“依赖方向”划分的用例表达层依赖数据驱动层和基础设施层基础设施层不依赖任何测试用例执行编排层是全局横切关注点不参与业务逻辑。这张图我贴在项目Wiki的首屏后来Code Review时发现绝大多数新人看一眼就知道自己的代码该放哪测试新增效率至少提升一倍。2. 环境准备与项目结构搭建2.1 创建测试项目的正确姿势以.NET 8为例假设解决方案根目录下已有被测项目MyApp.Business新建测试项目的命令如下dotnet new nunit -n MyApp.Business.Tests dotnet add MyApp.Business.Tests reference MyApp.Business cd MyApp.Business.Tests dotnet add package Microsoft.NET.Test.Sdk dotnet add package NUnit3TestAdapter dotnet add package coverlet.collector这里的三个包缺一不可Microsoft.NET.Test.Sdk是测试宿主NUnit3TestAdapter是Visual Studio/命令行测试发现器与nUnit之间的桥coverlet.collector用于收集覆盖率数据。有个新手经常踩的坑只看教程安装了NUnit和NUnit3TestAdapter忘了装Microsoft.NET.Test.Sdk结果dotnet test跑不起来或者说测试发现不了。另外注意.NET Core时代不要装NUnit2TestAdapter那是给.NET Framework老项目用的混装会导致诡异的双适配器冲突。2.2 项目目录结构的标准化设计我强烈建议测试项目内部也做分层不要把所有测试类平铺在根目录。我的标准结构是这样MyApp.Business.Tests/ ├─ AssemblyInfo.cs ├─ Fixtures/ │ ├─ OrderServiceTests.cs │ ├─ PaymentServiceTests.cs │ └─ InvoiceGeneratorTests.cs ├─ Data/ │ ├─ OrderTestData.cs │ ├─ PaymentTestCases.cs │ └─ JsonData/ │ ├─ orders.json │ └─ payment.invalid.json ├─ Infrastructure/ │ ├─ TestDatabase.cs │ ├─ MockHttpServer.cs │ └─ FakeTimeProvider.cs ├─ Utilities/ │ ├─ RandomDataGenerator.cs │ └─ AssertExtensions.cs └─ Integration/ ├─ OrderFlowIntegrationTests.cs └─ PaymentRetryIntegrationTests.csFixtures下放单元测试Integration下放跨模块集成测试Data集中管理数据源Infrastructure放测试基础设施。注意这里有一个关键约定避免在单位测试目录里偷偷访问数据库如果某个测试需要连数据库就放到Integration目录并打上[Category(Integration)]标签。这个约定靠人自觉不好维持我后来在CI脚本里加了强制过滤只跑Unit类别从机制上把两类测试分开。2.3 AssemblyInfo全局配置的细节nUnit 3把全局配置放在AssemblyInfo.cs在nUnit项目中加了这些内容using NUnit.Framework; [assembly: LevelOfParallelism(4)] [assembly: Parallelizable(ParallelScope.Fixtures)] [assembly: NonParallelizable]这里要注意NonParallelizable和Parallelizable同时存在时的优先级容易让人困惑。简单说Fixture方法上的特性优先级最高然后依次是Fixture类、程序集越具体越优先。所以我习惯的做法是程序集层面全局开启Fixtures级别的并行关闭方法级别并行再在个别需要并行的Fixture类上用Parallelizable(ParallelScope.Self)覆盖。并行执行不是免费的如果两个Fixture共享同一个静态类或数据库分分钟出偶发失败。我第一次开并行时测试速度提了4倍但随机红了一批用例排查半天发现是共享的静态Mock。所以开并行之前先保证每一个Fixture的资源完全隔离。3. 核心功能实现与封装细节3.1 生命周期方法的选择策略nUnit的生命周期方法看起来简单但用对了才能减少大量重复代码。我的选择策略一条条说清楚[OneTimeSetUp]整个Fixture运行前执行一次适合数据库迁移、启动Mock HTTP Server、准备大文件等重量级操作。注意它跟[SetUp]的区别很多人都栽在这里——[SetUp]是每个测试方法执行前都会调一次[OneTimeSetUp]只调一次。[TearDown]每个测试方法跑完后执行适合清理当前用例产生的临时文件、重置静态变量、删除测试数据。[OneTimeTearDown]整个Fixture结束后执行适合释放数据库连接、停掉HTTP Server。举个例子测试OrderService时需要内存数据库如果每次SetUp都new一个性能极差但如果全部用例共用一个数据库又可能出现用例间数据污染。我的折中方案是OneTimeSetUp里初始化数据库结构并开启事务SetUp里开一个新事务TearDown里回滚事务这样每个用例看到的是干净快照性能还高。3.2 数据驱动的三种玩法nUnit的数据驱动是它最强的地方之一我按复杂度从低到高列一下最基础的[TestCase]适合固定几组小数据。[TestCase(1, 2, 3)] [TestCase(10, 20, 30)] [TestCase(0, 0, 0)] public void Add_ShouldReturnExpectedSum(int a, int b, int expected) { var result Calculator.Add(a, b); Assert.That(result, Is.EqualTo(expected)); }进阶的[TestCaseSource]适合从静态类、外部文件、数据库读取的大批量数据。数据源必须是静态方法或静态属性且参数和返回值必须匹配。public static IEnumerableTestCaseData InvalidOrderData() { yield return new TestCaseData(null, 订单号不能为空); yield return new TestCaseData(, 订单号不能为空); yield return new TestCaseData(ABC, 订单号格式不正确); } [TestCaseSource(nameof(InvalidOrderData))] public void Validate_ShouldReturnErrorMessage(string orderNo, string expectedMessage) { var result OrderValidator.Validate(orderNo); Assert.That(result, Does.Contain(expectedMessage)); }重量级玩法[TestCaseData SetName Category]当用例达到几十上百条时默认显示的名字根本分不清业务含义此时用SetName给用例设置中文别名或业务名报表瞬间直观。public static IEnumerableTestCaseData PaymentScenarios() { yield return new TestCaseData(100m, CNY, 100m) .SetName(等额支付-人民币-全额) .SetCategory(Payment); yield return new TestCaseData(100m, USD, 715.32m) .SetName(跨币种支付-美元-按汇率折算) .SetCategory(Payment); }实际项目里我还会用TestCaseData的Explicit属性控制某些用例只在手动点击时执行以及用Ignore属性临时跳过失败的已知bug用例。但注意Ignore不能成为常态我要求团队任何用例Ignore时间不超过一个迭代否则一律删除重建。3.3 断言该用经典模式还是约束模式nUnit 3里断言有两种写法经典模式Assert.AreEqual和约束模式Assert.That(actual, Is.EqualTo(expected))新项目我强推约束模式。原因不只是美观而是约束模式的失败信息详细得多。比如字符串包含失败经典模式只告诉你“Expected: contains x, But was: y”约束模式还能显示实际字符串中哪个位置不匹配、索引是多少排查效率天差地别。再补充一些用得最多的约束值得收藏数值断言Is.EqualTo(3.14).Within(0.01)浮点比较必备不然你永远不知道为什么算出来的结果对不上。集合断言Does.Contain、Is.EquivalentTo忽略顺序的相等、Is.Unique、Is.Ordered在测试List去重和排序的时候省太多事了。异常断言不要用try/catch包起来再Assert.Fail直接Assert.That(() service.Pay(null), Throws.TypeOfArgumentException().With.Message.Contains(订单号))。异步断言nUnit 3原生支持async Task测试方法可直接用Assert.That(async () await service.GetAsync(1), Is.Not.Null)。3.4 测试替身的正确使用边界全功能测试项目一定会涉及Mock比如Moq、NSubstitute。但很多人误以为测试替身就是“无脑Mock一切”。我的原则是Mock外部依赖HttpClient、数据库仓库接口、文件系统接口这些必须Mock保证单元测试不依赖真实网络和环境。Mock边界服务发送邮件、短信、调用第三方支付这类服务Mock后要有明确的验证断言验证“调用过且参数正确”。不要Mock自己写的业务类如果测试OrderService时Mock掉OrderValidator那这个测试基本是在自欺欺人验证的是Mock库有没有按配置返回而不是业务逻辑。在项目里我用NSubstitute搭配nUnit比较多因为NSubstitute的语法更简洁Received(1)表示调用次数断言感觉比Moq的Verify顺眼。NSubstitute有个隐藏坑如果方法返回Task用sub.FindAsync(1)需要小心必须直接return Task.FromResult或使用ReceivedWithAnyArgs否则可能拿不到预期的纤程调度结果。4. 架构图绘制要点与执行策略设计4.1 架构图应该画到什么粒度项目标题里特意带上了“架构图”我推测是要向团队展示设计能力。测试项目的架构图切忌画成一个大圆环包一堆方块那是给老板看的“心理安慰图”。真正有用的架构图应该画到“类”与“接口”这一层至少要让读者看到每个Fixture依赖哪个基础设施。我画图的成品长下面这样不是mermaid就是最朴素的方块箭头------------------------------------------- | 执行编排层 (AssemblyInfo) | | LevelOfParallelism / CategoryFilter | ------------------------------------------- | | v v ------------------- ------------------- | 用例表达层 | | 数据驱动层 | | OrderTests |→| OrderTestData | | PaymentTests |→| PaymentCases | | InvoiceTests | | JsonDataLoader | ------------------- ------------------- | | v v ------------------- ------------------- | 基础设施层 | | 基础设施层(替身) | | TestDatabase | | MockHttpServer | | RealHttpClient | | FakeTimeProvider | ------------------- ------------------- | | --------------- v ------------------ | 被测系统边界 | | MyApp.Repository| | MyApp.Business | ------------------这张图的要点是画出了依赖方向一眼就能判断哪些测试依赖真实基础设施、哪些依赖替身。执行编排层虽然是全局配置但箭头画成松散虚线表示它更多是“策略”而不是“组件被依赖”。4.2 Category分组策略与CI流水线全功能测试项目必然要区分测试层级。我的做法是定义一套Category规范Category标签用途典型执行时机Unit纯内存单元测试每次pushIntegration依赖数据库、文件系统PR验证/每日构建Smoke关键路径冒烟测试发布前Slow耗时超过5秒的用例夜间全量构建CI脚本里对应着跑法# 只跑单元测试快、稳、反馈及时 dotnet test MyApp.Business.Tests --filter TestCategoryUnit --logger trx;LogFileNameunit.trx # PR验证时跑集成测试但跳过慢用例 dotnet test MyApp.Business.Tests --filter TestCategoryIntegrationTestCategory!Slow # 发布前全量 dotnet test MyApp.Business.Tests --filter TestCategorySmoke这里有一个很实用的变量--filter语法里的表示AND|表示OR!表示排除。nUnit的Category过滤规则有多种写法如果不小心把TestCategory拼成Category测试会全部被过滤掉也就是跑0个用例且“成功”退出这种假绿比真红更可怕。4.3 并行执行实战调优关于并行我再分享一组实测数据。一个拥有320个单元测试用例的项目单线程跑要100秒开启程序集级别的LevelOfParallelism(4)后时间降到35秒但此时同步静态依赖的用例开始偶发失败。我的最终方案是90%的Fixture用ParallelScope.Fixtures并行共享统一数据库的Fixture打上[NonParallelizable]强制串行每个Fixture内部的方法级默认串行只有纯函数、无状态的测试方法所在的类再显式开方法级并行。另外在输出日志时一定要带上TestContext.CurrentContext.Test.Name并行时日志乱序是常态没有用例名做前缀排查问题简直地狱难度。5. 实操过程从零到一构建一个完整测试项目5.1 搭建被测系统模拟环境为了让读者能完整复现我设计了一个迷你业务场景一个OrderService负责生成订单、校验库存、计算应付金额、支持跨境支付汇率换算。被测项目结构很简单public interface IProductRepository { TaskProduct GetByIdAsync(int id); Taskbool DeductStockAsync(int productId, int quantity); } public interface IPaymentGateway { TaskPaymentResult ChargeAsync(decimal amount, string currency); } public class OrderService { private readonly IProductRepository _productRepository; private readonly IPaymentGateway _paymentGateway; public OrderService(IProductRepository productRepository, IPaymentGateway paymentGateway) { _productRepository productRepository; _paymentGateway paymentGateway; } public async TaskOrder CreateOrderAsync(int productId, int quantity, string currency) { var product await _productRepository.GetByIdAsync(productId); if (product null) throw new ArgumentException(商品不存在, nameof(productId)); if (product.Stock quantity) throw new InvalidOperationException(库存不足); var amount product.Price * quantity; var paymentResult await _paymentGateway.ChargeAsync(amount, currency); if (!paymentResult.Success) throw new InvalidOperationException($支付失败: {paymentResult.ErrorMessage}); return new Order { Id Guid.NewGuid(), ProductId productId, Quantity quantity, TotalAmount amount, Currency currency, Status OrderStatus.Paid, PaymentReference paymentResult.Reference }; } }5.2 为OrderService编写完整的nUnit测试现在写一个符合“全功能”标准的测试类覆盖正常路径、业务异常、边界数据、Mock验证using NUnit.Framework; using NSubstitute; namespace MyApp.Business.Tests.Fixtures; [TestFixture] [Category(Unit)] public class OrderServiceTests { private IProductRepository _productRepository; private IPaymentGateway _paymentGateway; private OrderService _orderService; [SetUp] public void SetUp() { _productRepository Substitute.ForIProductRepository(); _paymentGateway Substitute.ForIPaymentGateway(); _orderService new OrderService(_productRepository, _paymentGateway); } [Test] public async Task CreateOrderAsync_WithValidInput_ShouldReturnPaidOrder() { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 10 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); _paymentGateway.ChargeAsync(200m, CNY) .Returns(Task.FromResult(new PaymentResult { Success true, Reference P001 })); var order await _orderService.CreateOrderAsync(1, 2, CNY); Assert.That(order.Status, Is.EqualTo(OrderStatus.Paid)); Assert.That(order.TotalAmount, Is.EqualTo(200m)); Assert.That(order.PaymentReference, Is.EqualTo(P001)); await _productRepository.Received(1).DeductStockAsync(1, 2); await _paymentGateway.Received(1).ChargeAsync(200m, CNY); } [Test] public void CreateOrderAsync_WhenProductNotExist_ShouldThrowArgumentException() { _productRepository.GetByIdAsync(999).Returns(Task.FromResultProduct(null)); var ex Assert.ThrowsAsyncArgumentException( () _orderService.CreateOrderAsync(999, 1, CNY)); Assert.That(ex.ParamName, Is.EqualTo(productId)); Assert.That(ex.Message, Does.Contain(商品不存在)); } [TestCase(0)] [TestCase(-1)] [TestCase(int.MinValue)] public void CreateOrderAsync_WhenQuantityIsInvalid_ShouldThrowArgumentOutOfRangeException(int quantity) { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 100 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); Assert.ThrowsAsyncArgumentOutOfRangeException( () _orderService.CreateOrderAsync(1, quantity, CNY)); } [Test] public void CreateOrderAsync_WhenStockNotEnough_ShouldThrowInvalidOperationException() { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 5 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); var ex Assert.ThrowsAsyncInvalidOperationException( () _orderService.CreateOrderAsync(1, 10, CNY)); Assert.That(ex.Message, Does.Contain(库存不足)); await _productRepository.Received(0).DeductStockAsync(Arg.Anyint(), Arg.Anyint()); } [Test] public void CreateOrderAsync_WhenPaymentFails_ShouldThrowAndNotCreateOrder() { var product new Product { Id 1, Name 测试商品, Price 100m, Stock 10 }; _productRepository.GetByIdAsync(1).Returns(Task.FromResult(product)); _paymentGateway.ChargeAsync(100m, CNY) .Returns(Task.FromResult(new PaymentResult { Success false, ErrorMessage 余额不足 })); var ex Assert.ThrowsAsyncInvalidOperationException( () _orderService.CreateOrderAsync(1, 1, CNY)); Assert.That(ex.Message, Does.Contain(余额不足)); await _productRepository.Received(1).DeductStockAsync(1, 1); } }注意几个细节[TestFixture]在nUnit 3中可以省略但我习惯保留提示读者这是个Fixture类Received(0)表示验证从未调用这个在防止“绕过关键逻辑”时非常有用Assert.ThrowsAsync返回异常对象可以继续断言异常参数名和消息比只写一行Assert.Throws信息量大得多。5.3 数据驱动测试进阶从Json读取测试用例当业务规则复杂时TestCase写在代码里会越来越臃肿。我通常会把场景数据迁移到Json文件中资源文件标记为CopyToOutputDirectory[ { productId: 1, quantity: 2, currency: USD, expectedAmount: 1430.64, expectedCurrency: USD }, { productId: 2, quantity: 3, currency: EUR, expectedAmount: 1075.47, expectedCurrency: EUR } ]搭配一个静态数据源类public static class OrderTestData { public static IEnumerableTestCaseData FromJson() { var jsonPath Path.Combine(TestContext.CurrentContext.TestDirectory, Data, order_cases.json); var rows JsonSerializer.DeserializeListOrderTestCase(File.ReadAllText(jsonPath)); foreach (var row in rows) { yield return new TestCaseData( row.ProductId, row.Quantity, row.Currency, row.ExpectedAmount) .SetName($订单-商品{row.ProductId}-数量{row.Quantity}-币种{row.Currency}) .SetCategory(DataDriven); } } }测试方法只需一条[TestCaseSource][TestCaseSource(typeof(OrderTestData), nameof(OrderTestData.FromJson))] public async Task CreateOrderAsync_WithExternalData_ShouldCalculateCorrectAmount( int productId, int quantity, string currency, decimal expectedAmount) { var product new Product { Id productId, Name 商品, Price 100m, Stock 100 }; _productRepository.GetByIdAsync(productId).Returns(Task.FromResult(product)); _paymentGateway.ChargeAsync(expectedAmount, currency) .Returns(Task.FromResult(new PaymentResult { Success true, Reference T001 })); var order await _orderService.CreateOrderAsync(productId, quantity, currency); Assert.That(order.TotalAmount, Is.EqualTo(expectedAmount)); }一定要用TestContext.CurrentContext.TestDirectory来定位资源文件不要用Environment.CurrentDirectory。dotnet test执行时的工作目录不是项目目录我在这个坑上浪费了整整一个下午导致CI全部找不到Json文件。5.4 集成测试与数据库事务隔离集成测试比单元测试复杂在外部依赖。以数据库为例我不会直接用生产库而是在OneTimeSetUp里创建内存SQLite数据库并执行迁移脚本在SetUp里开启事务TearDown里回滚。这样测试时无需清表用例之间互不干扰且速度远快于真实数据库。[TestFixture] [Category(Integration)] public class OrderFlowIntegrationTests { private SQLiteConnection _connection; private DataContext _dataContext; [OneTimeSetUp] public void OneTimeSetUp() { _connection new SQLiteConnection(Data Source:memory:); _connection.Open(); _dataContext new DataContext(_connection); _dataContext.Database.EnsureCreated(); } [SetUp] public void SetUp() { _transaction _connection.BeginTransaction(); } [TearDown] public void TearDown() { _transaction.Rollback(); } [OneTimeTearDown] public void OneTimeTearDown() { _connection.Dispose(); } }SQLite内存库的:memory:连接只要关闭连接数据全部消失所以必须保持连接开启而每个事务回滚后所有已执行的Insert/Update都会撤销这在测试数据造数和清理方面是神兵利器。真实业务系统如果用SQL Server可以换成本地容器里的SQL Server镜像但代价是速度慢不少。6. 常见问题与排查技巧实录6.1 测试发现不了或执行报错最常见的问题是“我写了测试方法为什么dotnet test一个case都不跑”优先级排查如下检查测试类是否标注了[TestFixture]nUnit 3虽然可以自动识别但在某些项目配置下漏标会不发现测试方法是不是public且返回void或Task如果不是nUnit不会执行确认项目引用了Microsoft.NET.Test.Sdk和NUnit3TestAdapter用dotnet test --list-tests列出所有测试如果这里没显示说明测试发现阶段就有问题别急着改成测试内容如果是类库而不是测试项目无法执行需要dotnet new nunit重新生成项目模板。6.2 用例跑挂但不知道是哪个步骤出的问题并行开着的时候日志全乱。我的解决办法是三步先关并行AssemblyInfo.cs里把LevelOfParallelism改成1在测试方法里打日志时加TestContext.Progress.WriteLine而不是Console.WriteLine因为nUnit默认会捕获Console输出可以在测试结果附件里查看利用TestContext.CurrentContext.Test.FullNameLogger里把这个打到每行日志最前面排序后用grep过滤单个用例日志。6.3 偶发失败与“测试污染”偶发失败九成是共享状态污染。用这个排查顺序检查静态字段有没有被某个用例修改且没有还原检查是否所有外设Mock都在SetUp里重新创建而不是放在OneTimeSetUp里检查数据库测试是否用了共享事务每用例回滚检查并行Fixture是否操作了相同文件如果有给文件路径按TestContext.CurrentContext.Test.ID加上独立后缀。6.4 覆盖率的正确追求方式覆盖率不是越高越好这是我做了十年测试架构最深刻的体会之一。nUnit配合coverlet统计很方便dotnet test MyApp.Business.Tests --collect:XPlat Code Coverage然后生成报告dotnet tool install -g dotnet-reportgenerator-globaltool reportgenerator -reports:TestResults/**/coverage.cobertura.xml -targetdir:coveragereport -reporttypes:Html我的经验是核心业务模块的单元测试覆盖率争取85%以上基础设施层比如HttpClient封装、数据库仓储可以低一些但关键分支要有测试兜底。不要为了数字好看去写一堆断言空的垃圾测试那是自欺欺人CI里甚至可以在平台层面限制覆盖率低于阈值视为失败。7. 经验心得与工程化建议整套nUnit全功能项目做下来有几条体会越来越深。一是测试代码和业务代码一样需要评审它是有读者、有维护成本的资产不是随手扔掉的草稿纸二是数据驱动和分层隔离是测试工程的两条主线能解决真实的维护痛点三是架构图不只是一张图它承载的是一种约定画出来之后要有人遵守、有人维护否则三个月后就成了一堆摆设。拿这个项目来说我最后还把架构图对应的目录结构同步到了实体项目的Wiki里在Doc中写清楚每个目录应该放什么、禁止放什么新人入职第一天看着图就能动手写测试。这种工程化收益远比单个测试代码写的多来得重要。如果你正准备在自己的团队推行这套方案我建议你先从小范围试点开始挑一个核心业务模块按文中这几步把测试工程搭起来跑上两个迭代再决定是否推广。测试框架本身没有那么多玄学真正拉开差距的还是工程规范和团队共识。最后再分享一个小技巧每次跑完完整测试套件养成看失败截图和日志文件的习惯哪怕全绿也要扫一眼警告信息很多隐藏的地雷都是这时候被揪出来的。
