Appearance
单元测试跑起来了，为什么后来又停了？
为了让遗留系统中逐步补充的单元测试能够定期执行，我曾使用阿里云云效建立了一条独立的定时流水线。
这条流水线不仅负责执行 UT，还会使用 Allure 3 生成测试报告，再将报告部署到另一台服务器，供开发人员通过浏览器查看。
后来，公司因云效相关资源费用，要求清理多条流水线，我建立的 UT 流水线也是其中之一。
按照要求删除流水线后，原有的定时执行机制停止了，但项目中的单元测试代码仍然保留。
本文希望通过这条 UT 流水线从建立到停止的真实经历，展示同一个工程问题在技术实践、资源成本、研发效率和长期治理上的不同侧面。任何单一视角，都可能不足以支撑完整的工程判断。
一、为什么要让单元测试自动运行？
1.1 写了 UT，不代表它会持续执行
在维护遗留系统时，我逐步为部分业务逻辑补充了单元测试（Unit Test，简称 UT）。
这些测试能够验证计算结果、协议转换以及部分边界和异常行为，但测试代码保存在仓库中，并不意味着它们会被持续执行。
在我接触过的项目中，UT 并不总是代码提交或上线前的强制要求。是否执行，往往取决于开发人员是否主动运行。
因此，我希望建立一种不完全依赖个人习惯的验证方式。
1.2 为什么选择定时验证？
当时的想法很简单：让现有 UT 定期执行，并通过报告查看执行结果。
这不需要修改原有发布流程，也不要求每位开发人员在固定时间手动执行测试。
自动执行解决的是测试如何运行的问题。测试失败以后，仍然需要开发人员判断原因并进行处理。
二、我当时建立了一条怎样的流水线？
2.1 Maven 与 Allure 3：从测试结果到可视化报告
流水线首先通过 Maven 执行 UT，生成测试结果数据。
如果只运行 Java 单元测试，并不需要 Node.js。但我当时希望拥有一份能够通过浏览器查看的报告，而不仅是流水线任务的成功或失败状态。
我之前使用过 Allure 2，后来选择了 Allure 3，因为新版的页面样式、信息组织和内容展示更符合我的使用习惯。
Allure 3 的报告生成工具链涉及 Node.js，因此整条流水线除了 Maven，还需要准备相应的运行环境和工具。
这也意味着，测试本身的执行时间，并不等于整套流程的执行时间。
2.2 Node.js、SFTP 与 Nginx：报告怎样发布
当时采用的完整流程如下：
text
Maven 执行 UT
↓
Allure 3 生成测试报告
↓
压缩 HTML、JS 等静态文件
↓
通过 SFTP 上传压缩包
↓
目标服务器解压报告
↓
Nginx 提供静态页面访问这套流程除了执行测试，还涉及 Node.js 环境、报告生成、文件压缩、网络传输与远程文件操作。
其中任意一个环节出现环境或网络问题，都可能影响当次报告的生成和发布。
这是我当时采用的部署方案，并不是 Allure 3 的通用要求。
实际执行情况是：每天上午 11:00 定时运行一次，整个测试、报告生成与发布流程通常耗时 3～5 分钟。
按每月 30 天估算，累计运行时间约为 90～150 分钟。不过，这只是完整流程的运行时间，不能直接等同于云效计费的构建核分。
2.3 为什么没有加入原有发布流程？
一个自然的疑问是：既然公司已有发布流水线，为什么不直接把 UT 放进去？
当时主要考虑的是尽量减少原有发布流程的耗时和不确定性。
单独执行 Maven UT 可能很快，但完整流程还包含 Node.js 环境准备、Allure 报告生成、SFTP 上传和远程部署。
如果全部加入已有发布流水线，就可能增加发布等待时间，也可能因为报告部署或网络问题影响原本正常的发布任务。
因此，我选择独立定时执行，不将整套报告流程放到生产发布的关键路径中。
但这种方式也有局限：定时执行无法保证每次发布前，最新代码都已通过 UT。
2.4 合并流水线，就能节省资源费用吗？
还有一种看法是：既然独立流水线会产生费用，把它合并到现有发布流水线就可以了。
但需要区分流水线数量与计算资源消耗。
阿里云云效托管构建资源的计量涉及构建时长、CPU 核数及构建集群系数等因素，并非简单按流水线数量收费。具体规则可参考阿里云云效按量计费说明。
因此，即使将相同的测试与报告生成任务合并进现有流水线，相关计算工作仍然需要消耗资源。
合并可能改变执行次数、缓存利用和环境准备方式，从而影响实际成本。真正需要评估的是任务的资源消耗及执行策略，而不只是减少一条流水线。
三、从运行到停止：一次流水线清理
3.1 公司要求清理多条流水线
这套机制建立后，能够按照配置执行 UT，并生成可访问的报告。
后来，公司检查云效的使用情况，认为相关流水线产生了额外费用，要求进行清理。
被要求清理的不只是 UT 流水线，还有其他流水线。
公司提供了相关后台链接，但没有向我提供具体的费用账单，因此我无法确认这条 UT 流水线实际产生了多少费用。
这是一项涉及多条流水线的资源清理要求，不能据此认定公司专门针对单元测试。
3.2 删除执行机制，保留 UT 代码
收到要求后，我按照安排删除了对应的 UT 流水线。
原有的定时测试与报告生成机制因此停止，但 UT 代码依然保留在项目中，开发人员仍然可以根据需要执行。
停止自动执行以后，原本由这套机制承担的验证工作，又会发生什么变化？
四、一套工程机制的成本与价值，应该怎样衡量？
不同角色关注的成本与收益可能并不相同。
负责资源管理的人可能先看到流水线费用，开发人员可能更关注测试能否持续运行，技术负责人则可能考虑维护责任和交付风险。
如果希望对一套工程机制作出更完整的判断，我认为至少需要观察四个维度。
4.1 资源投入：它需要消耗什么？
当时，这条 UT 流水线每天上午 11:00 执行一次，整个测试、报告生成与发布流程通常耗时 3～5 分钟。
其中除了 Maven 测试，还包括 Allure 3 报告生成及相关环境准备。这些任务会消耗云效构建资源，但完整流程的运行时长不能直接等同于计费核分。
停止定时执行可以减少相关计算任务的资源消耗。实际账单变化多少，则需要结合构建资源规格、套餐额度和费用记录判断。
资源费用是工程成本的一部分，却不是评价机制价值的全部依据。
4.2 研发时间：人工投入如何衡量？
开发人员的工资是明确的企业支出，但工作时间可能分散在需求开发、测试验证、缺陷修复和系统维护等活动中，这些投入不一定都被单独统计。
在这次实践中，流水线能够自动完成 Maven 测试、Allure 报告生成及报告部署，减少了每次执行这些操作对人工触发的依赖。
如果停止自动化以后，需要开发人员手动完成部分验证工作，即使工资总额不变，这些工作仍然会占用原本可以投入其他任务的时间。这就是时间的机会成本。
但自动化机制本身同样需要开发和维护。因此，评价一套机制时，需要同时考虑自动化的维护投入，以及没有自动化时可能发生的替代投入。
4.3 验证收益：它究竟保护了什么？
当时积累的 UT 主要用于验证部分业务计算、协议转换以及边界和异常行为。建立定时流水线，是为了让这些已有测试获得规律的执行机会。
但执行次数并不能直接代表验证收益。还需要了解测试失败是否对应真实问题、报告是否得到查看，以及发现的问题是否得到处理。
这次清理后，我没有继续统计缺陷发现情况和研发工时变化。因此，只能分析几种可能的结果：开发人员改为手动执行、测试执行频率下降，或者由其他验证方式承担部分工作。
不同结果对应不同的人工投入和风险，实际影响仍需要数据验证。
4.4 持续维护：谁负责让机制长期有效？
技术上搭建一条流水线，并不意味着它可以长期无人维护。
例如，业务规则改变后，谁负责更新 UT？测试失败后，谁负责查看报告和定位原因？
Allure 或构建环境发生变化时，谁负责调整？运行成本发生变化时，又由谁决定继续投入、优化或停止？
开发人员能够独立完成技术实现，但一项需要长期使用企业资源的工程机制，其维护和资源决策通常还涉及其他角色。
能把机制建立起来，与能让机制长期有效，是两个不同阶段的问题。
五、如果重新建立这套机制，我会考虑什么？
回头看当时的方案，我发现还有一些可以进一步评估的地方。
这些属于事后复盘，并不是当时已经实施过的措施。
5.1 定时执行、提交触发与发布门禁的取舍
如果采用提交触发，业务代码发生变化后，可以更及时地执行相关 UT；即使测试文件本身没有修改，也可能需要重新验证。
但如果每次提交都执行完整测试，实际资源消耗可能随着提交频率增加。
发布门禁能够强化上线前检查，却需要考虑测试稳定性、执行时长以及对交付流程的影响。
如果重新设计，我会先了解实际代码提交频率、测试规模、资源消耗和业务风险，再决定使用哪一种触发策略。
5.2 将 UT 执行与报告生成、发布拆分
这一点是后来复盘时才意识到的。
当时，我将 Maven UT 执行、Allure 3 报告生成、SFTP 上传和远程部署放在同一条流水线中。
这样可以一次完成全部流程，但也意味着报告相关的环境和部署问题可能影响整条任务的成功状态。
实际上，UT 执行、报告生成和报告发布可以分别设计。
例如，测试执行后先保留测试结果，再由独立任务根据需要生成和部署报告。
如果重新设计，我会优先评估将 UT 执行与报告生成、发布拆分，而不是直接恢复原来的一体化流水线。
这种方式可以提供更灵活的执行选择，减少部分环节之间的相互依赖，但是否节省资源仍需要通过运行数据确认。
5.3 用数据评估资源消耗与验证价值
当时，我已经能够掌握流水线的执行频率与整体运行时长，但没有建立完整的资源消耗和验证收益统计。
如果重新建立类似机制，除了这些基础执行信息，我还希望记录：
- 实际构建资源消耗；
- UT 通过、失败及失败原因；
- 有多少失败对应真实问题；
- 测试结果是否得到及时查看和处理。
有了这些信息，才更容易判断执行频率是否合理、哪些环节值得优化，以及这套机制是否值得持续投入。
这些记录也可以成为开发人员向资源决策者说明方案的依据，而不是仅仅依靠“单元测试很重要”来证明价值。
结语：工程判断需要不止一个视角
这次经历的最终结果，是一套原本能够定时执行 UT、生成并发布测试报告的流水线停止了，但测试代码仍然保留。
技术上可以重新建立它，也可以采用不同的触发和报告方案。
然而，是否值得持续运行，不能只凭技术上能够实现来决定，也不能只看单次构建费用。
工程判断不是寻找一个永远正确的方案，而是在真实约束下，尽可能看清它的成本、收益、风险和长期维护责任。
不同角色可能得出不同的合理结论。如果这段经历能够让读者在面对类似问题时，多考虑一个过去没有注意到的因素，那么它就具有了超出一次流水线实践记录的价值。