不使用类，借助文件级变量进行MATLAB单元测试的方案探讨

核心问题总览 #

靠全局结构体P来模拟Python的文件级/外部变量导入，绕开matlab.unittest.TestCase，会踩一堆可靠性、可维护性的坑，尤其是并发跑测试时问题会被放大。

具体弊端拆解 #

1. 并发测试必踩的竞态条件与数据污染 #

MATLAB用parpool并行执行测试时，全局变量是所有并行工作区共享的——这和Python多进程的全局变量拷贝逻辑完全不同：

• 测试A在修改P.config的中途，测试B读取到半修改的脏数据，直接导致断言失败
• 某测试结束后没重置P，后续测试会继承被篡改的状态，出现“有时过有时挂”的玄学问题
• 并行场景下，多个测试同时写P的同个字段，最终值完全不可预测，根本没法稳定复现问题

2. 彻底破坏测试独立性 #

单元测试的核心要求是用例之间互不影响，全局P直接打破这个原则：

• 测试用例的执行顺序决定结果，比如测试1改了P.threshold，测试2必须在测试1之后跑才能通过
• 想单独调试某一个测试用例？不可能，得先跑完全部前置测试，调试效率直接拉垮

3. 维护起来噩梦级 #

• P的字段没有统一的定义入口，各个测试文件都可能加字段、改值，新人接手根本搞不清哪些字段被谁用了
• 要是改了P的某个字段名或类型，所有依赖它的测试都得手动改，漏一个就炸
• 没法像官方框架的TestParameter那样做参数化测试，只能硬改P的值写重复代码，冗余到爆炸

4. 没有自动隔离与清理机制 #

官方测试框架会给每个用例建独立工作区，跑完自动清场。但全局P得自己写清理逻辑：

• 忘了重置？下一个测试就带着上一个测试的脏状态跑
• 手动清理很容易漏，比如只重置了几个常用字段，冷门字段残留的脏数据藏着等你踩雷

5. 调试难度直接拉满 #

测试失败时，你根本分不清是P初始值错了，还是某个测试改了P导致的：

• 没有框架帮你记录P的修改轨迹，只能挨个测试翻代码排查
• 并发场景下的偶发失败，几乎不可能复现，因为竞态条件的触发时机完全随机

替代方案（务实版） #

如果就是想复用外部变量，别用全局结构体：

• 把外部变量封装成函数，每个测试用例独立调用获取初始值，保证隔离
• 哪怕不用TestCase的全部功能，至少用setup脚本给每个测试初始化独立的变量副本，别碰全局

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