如何调试VS2019中批量运行NUnit3单元测试时随机挂起的问题

1 优先验证并行执行导致的死锁问题 #

NUnit3默认启用测试并行执行，NUnit2默认单线程执行，这是最常见的引发随机挂起的原因，本质是测试用例间未处理共享资源竞争：

• 先关闭全局并行验证：在测试项目的AssemblyInfo.cs中添加[assembly: Parallelizable(ParallelScope.None)]，重新编译后全量执行，如果不再挂起，可确认是多线程资源竞争导致的死锁。
• 已确认是并行问题后，可通过进程转储定位死锁点：当执行器挂起时，打开任务管理器找到对应执行进程（如nunit3-console.exe），右键选择「创建转储文件」，用Visual Studio打开转储文件查看各线程调用栈，重点排查Monitor.Enter、ReaderWriterLockSlim等锁等待语句，以及静态变量、单例实例、共享文件/数据库连接等跨用例共享资源的争抢逻辑。

2 验证NUnit3行为变更引发的资源累积问题 #

如果关闭并行后仍出现挂起，重点排查以下NUnit3和NUnit2的行为差异点：

• 异步测试规范：NUnit3对async void类型的测试用例处理逻辑与NUnit2不同，未观察的异常、同步上下文阻塞会随着执行用例数增加累积，最终导致进程挂起，需将所有异步测试方法的返回值从void改为Task。
• 测试上下文访问：NUnit3的TestContext不支持跨线程传递，如果有用例在异步回调、后台线程中访问TestContext，会引发不可预期的资源泄漏，执行过程中可通过任务管理器观察测试执行进程的句柄数、线程数、内存占用，如果数值随执行用例数持续上涨无回落，即可确认存在资源泄漏。
• 清理逻辑适配：NUnit3的OneTimeSetUp/OneTimeTearDown、SetUp/TearDown的执行顺序、作用域与NUnit2存在差异，需检查全局清理逻辑是否存在未释放的非托管资源，如网络连接、文件流、互斥量等。

3 通过运行器参数缩小排查范围 #

使用nunit3-console执行测试时可添加以下参数辅助定位：

• 添加--trace=Verbose参数生成详细运行日志，查看挂起前最后执行的操作，确认是执行测试用例、卸载程序集还是执行清理逻辑阶段出现阻塞。
• 添加--workers=1参数强制单线程执行，排除测试运行器层面的多线程调度问题。
• 添加--dispose-runners参数，要求每个测试类执行完成后立即释放对应的运行器实例，避免资源跨测试类累积。

4 分批次执行缩小问题范围 #

如果上述方案仍未定位到根因，可将全量测试用例按命名空间、测试类拆分成分批执行的子集，逐步缩小可复现挂起的最小用例集合，再针对该集合的用例排查共享依赖逻辑。

内容的提问来源于stack exchange，提问作者Vinit Sankhe