📚 课程目录第3章 MATLAB单元测试框架选型

3. MATLAB单元测试框架选型

在MATLAB工程中做单元测试，最先遇到的不是“怎么写断言”，而是“用哪套框架”。选错框架的代价往往在项目中期才暴露：CI流水线无法稳定产出JUnit报告、测试夹具难以复用、参数化用例写不动、团队新人上手成本高。本节把可选方案收敛为三类：MathWorks官方内置的 matlab.unittest、社区轻量的 xUnit 风格框架（以 MATLAB xUnit Test Framework 为代表）、以及第三方/自研框架（如基于 pytest 思路的 matlab-xunit 变体、企业自研断言库、或通过 Python 调用 MATLAB Engine 的混合方案）。选型不是比“谁功能多”，而是比“谁与你的工程约束最匹配”。

三类框架的本质差异

matlab.unittest 是随 MATLAB 发布的官方框架，核心对象是 TestCase 子类，通过 methods (Test) 块声明测试方法，用 verifyEqual、assertError、verifyThat 等限定符表达断言。它的最大优势是“与 MATLAB 生态同源”：支持 TestSuite、TestRunner、TestResult 完整对象链，能直接输出 TAP、JUnit XML 等格式，天然适配 Jenkins/GitLab CI；参数化通过 properties (TestParameter) 实现，夹具通过 TestMethodSetup/TestClassSetup 管理，还能用 matlab.unittest.plugins 扩展覆盖率与诊断。

xUnit 风格框架的设计哲学是“极简”。它通常只要求测试文件以 test_ 开头或函数名以 test 开头，断言用 assertEqual、assertTrue 这类函数，运行入口是一个 runtests 或 runxunit。优点是学习曲线几乎为零，适合脚本型项目、教学演示或遗留代码快速补测；缺点是缺少标准化的测试套件对象、报告格式有限、参数化和夹具能力弱，CI 集成往往需要自己写解析脚本。

第三方/自研框架则覆盖中间地带：有的把 xUnit 的简洁与 JUnit 报告结合，有的引入 mock 框架（如 matlab.mock 之外的第三方 mock 库），有的通过 Python 的 pytest 驱动 MATLAB Engine 实现跨语言测试。它们灵活，但引入外部依赖、版本兼容和维护风险，需要团队有明确的“自研成本”评估。

工程选型的四个硬约束

第一，CI 报告格式。如果测试要接入 Jenkins、GitLab CI 或 Azure DevOps，必须能产出 JUnit XML。matlab.unittest 通过 matlab.unittest.plugins.XMLPlugin 一行配置即可输出；xUnit 风格框架通常只打印文本，需要额外解析。第二，参数化与数据驱动。算法测试常需对多组输入输出批量验证，matlab.unittest 的 TestParameter 能把参数组合自动展开为独立用例，失败时精确定位到某一组；xUnit 风格往往要手写循环，失败信息粒度粗。第三，夹具与资源管理。涉及文件、数据库连接、临时目录时，TestClassSetup/TestMethodSetup 能保证前置与清理成对执行；轻量框架缺少这一层，容易留下脏状态。第四，团队技能与维护。官方框架文档完整、随版本升级，长期维护成本最低；第三方框架一旦作者停更，升级 MATLAB 版本时可能直接失效。

一个可执行的选型判断示例

假设某信号处理项目有 120 个测试用例，需要每天在 CI 上跑，并输出覆盖率报告。按上述约束：需要 JUnit XML → 排除纯 xUnit；需要参数化（不同信噪比、不同采样率组合）→ 排除轻量框架；团队无额外维护人力 → 排除自研。结论是 matlab.unittest。若换成“一个 20 行的教学脚本，只想快速验证几个边界值”，则 xUnit 风格的 assertEqual 加 runtests 已经足够，强行上官方框架反而增加样板代码。

下面给出一个 matlab.unittest 的最小可运行骨架，展示参数化与夹具的实际写法：

classdef TestMovingAverage < matlab.unittest.TestCase
    properties (TestParameter)
        window = {3, 5, 7};
        input  = {[1 2 3 4 5], [0 0 0 0 0]};
    end
    methods (TestMethodSetup)
        function preparePath(testCase)
            testCase.addTeardown(@() rmpath('src'));
            addpath('src');
        end
    end
    methods (Test)
        function testLength(testCase, window, input)
            y = movingAverage(input, window);
            testCase.verifyEqual(numel(y), numel(input));
        end
        function testConstantInput(testCase, window)
            y = movingAverage(ones(1,10), window);
            testCase.verifyEqual(y, ones(1,10), 'AbsTol', 1e-12);
        end
    end
end

运行方式为 results = runtests('TestMovingAverage')，或通过 TestSuite.fromClass 构建套件后交给 TestRunner 并挂载 XML 插件。判断结果时看 results.Passed、results.Failed 与 results.Duration，失败用例会给出参数组合与断言差异，这正是参数化带来的定位效率。

选型口诀：先看 CI 报告，再看参数化与夹具，最后看团队维护成本。三者都指向官方框架时，不要为了“轻量”而选 xUnit；三者都不需要时，也不要为了“完整”而过度设计。

决策表：把约束映射到框架

工程约束	matlab.unittest	xUnit 风格	第三方/自研
JUnit XML / TAP 报告	内置插件，开箱即用	需自行解析	取决于实现
参数化数据驱动	TestParameter 自动展开	手写循环	部分支持
夹具与资源清理	Setup/Teardown 成对管理	弱	视框架而定
mock 与覆盖率	官方 mock 与覆盖率插件	基本没有	可能引入额外依赖
学习与维护成本	中，但文档与升级有保障	低	高，存在停更风险
适用场景	工程化、CI、长期维护	脚本、教学、快速补测	有明确特殊需求时

最后强调一个常见误区：不要因为“官方框架代码看起来多”就转向 xUnit。样板代码是一次性成本，而报告缺失、参数化缺失、夹具缺失带来的是每次排障的重复成本。选型的本质是把一次性投入换成长期可维护性。对于绝大多数 MATLAB 工程，matlab.unittest 是默认答案；只有在明确不需要 CI 报告、不需要参数化、且团队规模极小时，才降级到 xUnit 风格。第三方框架则应作为“有明确缺口时的补丁”，而不是默认起点。