第六章 · 工具链：把循环装进流水线

第六章 · 工具链：把循环装进流水线

章节摘要：人盯不住几百条测试，机器可以。本章跟着灯塔小组把循环交给流水线：pytest 插件生态按需选装、CI 的三道关卡各有位次、编辑器里的监视模式把反馈周期压到秒级。工具是配角、节律是主角的立场贯穿全章——每样工具都为缩短"从改动到红灯"的距离服务。读完你应能搭出一套人与机器共同值守的反馈体系。

一条主线

迁移项目进入第二个月，灯塔小组的测试涨到了八百多条。新的烦恼换了模样：有人本地忘了跑测试就把代码推上去，集成层红灯半小时后才被发现；有人抱怨"测试太多，本地全跑要等四分钟"，于是干脆不跑了。解法是一套组合拳——本地用监视模式只跑受影响的用例，提交前跑单元层全量，流水线上分三道关卡按速度分层把守，慢的端到端只在合并前跑。章节结尾时，反馈周期从"最长四十分钟"压到"本地三秒、合并前一刻钟"，红灯重新变得可信。把这条主线再看细些会发现：三站之间的顺序不是随意的——先选对插件（工具到位），再排位次（时机到位），最后调体感（习惯到位）。跳过中间那站直接调体感的团队不少见，结果是本地跑得飞快、主干照样带红，快出来的都是错觉。

沿途站点

• pytest 生态与插件选型——插件多到眼花，按"解决什么反馈问题"分类选装：参数与夹具增强、覆盖率、顺序与重复、并行提速，以及"不装"的判断标准。
• CI 里的位次：提交前与流水线上——三道关卡的位次设计：本地秒级、提交单元层、合并前全量，红灯挡合并的规则与执行细节。
• 编辑器里的红灯：watch 模式与即时反馈——pytest-watch 与测试资源管理器，改动即跑、只跑受影响用例，把循环的体感从"跑测试"变成"看红绿"。

三站的深度刻意做了控制：每站只讲"选型与接线"，不讲工具的百科全书——工具细节迭代太快，而位次与反馈半径的原理很稳定。读的时候把注意力放在两个可迁移的判断上：这个工具缩短了哪段距离？这个位次安排让谁在最短时间看到什么？工具会换，这两个问题不会。

拐点与结论

本章的转折点是"反馈回路的分流"：不是所有测试都要在所有时机跑。改一行业务代码，受影响的用例秒级给答案；提交时，单元层全量给底线；合并前，慢而真的端到端给兜底——时机与层级配对，才叫流水线。结论随之而来：工具选型的唯一标准是"是否缩短了从改动到红灯的距离"，凡是拉长这个距离的工具（跑得慢、噪音大、维护贵），再流行也不装。

读完你应该

• 能按反馈问题为团队选装 pytest 插件，并说出至少三种"不该装"的情形；
• 能设计提交前与流水线上的分层执行方案，红灯挡合并的规则落地；
• 能配置 watch 模式与编辑器测试集成，让循环体感低于五秒；
• 能诊断团队的反馈回路瓶颈，指出延迟出在哪一环。

先决条件与本章配套

本章的配置动作都不重：pytest-watch 与两三个插件，加上流水线平台的访问权限。判断本章内容有没有读到位的办法很直接：读完之后，算算自己项目"从改动到红灯"的最短距离与最长距离——最短的应该在秒级（本地 watch），最长的应该有上限且有主（合并前的端到端）。两个数字都答不上来的，回去把 6.2 的位次图对着自己的流水线走一遍。

下一章的接力

工具与流水线就位后，还剩最难也最值钱的部分：人。第 7 章收束全册——反模式图鉴、度量的正确读法、以及把节律推广到整个团队的落地手册。