无测试遗留代码安全变更：用接缝…

当需要在无测试、难测试或继承来的混乱代码库中安全修 bug、加功能或重构，且不能直接大重写时使用。

适用场景

解决思路

1. 核心定义：把 legacy code 当作没有测试的代码，而不是旧代码或丑代码；没有测试就无法知道变更是否保持行为，因此每次编辑都是赌博。
2. 执行 cover and modify，绝不 edit and pray：先刚好打破依赖把测试放进去，再修改。
3. 按 0-10 给未测试代码变更评分，报告当前分数和达到 10/10 的具体步骤；目标 9-10 分标准是：变更点在任何编辑前被 characterization tests 覆盖，行为变更和重构作为分开的已验证步骤发布，依赖用最小侵入技术打破。
4. 运行五步遗留代码变更算法：识别 change points，找到 test points，打破依赖，写测试，然后做变更并重构。
5. 让测试前的编辑保守且机械；真正的变更只在安全网内进行。
6. 区分两类变更：改变行为（feature、bug fix）和改进结构（refactoring）；不要在同一步混合，否则失败无法诊断。
7. 把重构和行为变更拆成单独 commits，并确保每一步之间测试变绿。
8. 记住 test points 很少等于 change points：效果会传播，通常要在变更效果显现处测试，而不是编辑发生处。
9. 在测试存在前做 dependency-breaking edits 时，必须完全保持签名，并依赖编译器找出每个受影响位置。
10. 让覆盖沿你实际修改的路径增长，而不是等待一个专门且永远拿不到经费的 testing project。
11. 遵循一次只做一件事的编程方式，让算法每一步都可独立验证。
12. 在未测试模块修 bug 时，先运行五步再碰 bug：用测试 pin 住 parseInvoice()，然后修复 rounding error。
13. PR 混合 cleanup 和 feature 时，拆成 structure-only 和 behavior-only commits：先 extract 和 rename，测试变绿，再加 discount rule。
14. 面对“只是一行改动”时，先找最近的 test point：在调用你编辑的 private 方法的 public 方法上写一个 pin test。
15. 寻找 seam：seam 是可以在不编辑该处的情况下改变程序行为的位置；每个 seam 都有 enabling point，即决定运行哪段行为的位置。
16. 在 OO 代码中默认找 object seams：每个可覆盖调用都是 seam，其 enabling point 在对象被创建或传入处。
17. 在构建或加载时替换实现时使用 link 和 import seams；jest.mock 和 unittest.mock.patch 是现代形式的 link seams。
18. 把 preprocessing seams（C/C++ macros）作为最钝的工具，最后再考虑。
19. 识别 seam 死亡处：方法体内 new Database()、构造函数做实际工作、globals、statics、hard-wired I/O。
20. 记住没有可达 enabling point 的 seam 没用：如果测试无法做出选择，就继续找。
21. 在动态语言中，几乎每个名称查找都是 seam；这很便宜，但 patch internals 会让测试耦合到文件布局。
22. 类自己构造 DB client 时，用构造函数参数做 object seam：constructor(db: Db = new ProdDb())，测试传入 fake。
23. 模块调用顶层 send_email() 时，用 import/link seam：mocker.patch("billing.send_email") 或 jest.mock("./mailer")。
24. 逻辑直接读墙钟时，在 clock 处开 seam：注入 now() provider，测试冻结时间。
25. 写 characterization tests：记录代码当前实际做什么，而不是 spec、注释或任何人记忆中说它应该做什么。
26. 使用配方：在 harness 中调用代码，先断言荒谬值（例如 expect(total).toBe(-1)），读失败信息暴露真实行为，然后把断言改成固定观察到的值。
27. 知道打破依赖有两个原因：separation 让代码进入 harness，sensing 让断言看到代码计算出的结果。
28. 对复杂输出（reports、generated files、大 JSON）使用 golden master：捕获完整输出一次，之后永久 diff 对比。
29. 知道 snapshot tests 是 golden masters：第一次 snapshot 要像审查代码一样审查，并规范化易变数据，否则只是在固定噪声。
30. characterizing 时发现 bug：用注释和 ticket 固定它，因为 downstream code 可能依赖错误行为，之后作为独立的有意变更修复。
31. 只 characterization 你的变更会触及的分支，不要试图 characterization 整个系统；覆盖跟随变更。
32. 重构 tax calculator 时，为代表性输入固定输出：跑 20 个 cases，逐个断言记录结果。
33. 遇到 legacy report generator，用 golden master diff：生成报告，与 checked-in master file 对比。
34. 在 pinning 时发现 off-by-one，固定错误值并记录：assert days == 30 # BUG? expected 31 — TICKET-482。
35. 当今天确实无法让区域可测时，不要把新逻辑织进未测试的大块代码；用 Sprout Method 或 Sprout Class，把新行为写成全新的、完全测试的代码，并从 legacy 位置用一行调用它。
36. 新逻辑只在一个点接入时用 Sprout Method；host class 在测试 harness 中甚至无法实例化时用 Sprout Class。
37. 当新增行为围绕旧代码（logging、notification、metering）而不是混入旧代码时，用 Wrap Method：把 pay() 重命名为 rawPay()，重建 pay() 作为 wrapper。
38. 当多个调用点需要新增行为，或类已经臃肿时，用 Wrap Class，也就是 Decorator pattern。
39. 诚实看待取舍：host 仍未测试，你只是把好代码加到了坏邻居旁边。
40. 将 sprouts 作为 debt 跟踪并偿还：host 下次发生变更时覆盖它。
41. 把 sprouting 当作变更算法内部的战术动作，而不是让代码进入测试的永久替代方案。
42. 在 400 行 process() 中加 late-fee rule 时，用 Sprout Method 和一行调用 total += lateFee(order)，其中 lateFee() 测试先行。
43. 围绕 legacy pay() 加 audit logging 时，用 Wrap Method：新 pay() 先 log，调用 rawPay()，再 log。
44. 新增 validation 且类无法实例化时，用 Sprout Class：从 legacy code 调用 new OrderValidator().validate(data)。
45. 从依赖打破技术目录选招：Extract Interface、Parameterize Constructor、Parameterize Method、Extract and Override Factory Method or Getter、Introduce Instance Delegator、Adapt Parameter、Break Out Method Object、Subclass and Override Method。
46. 因为这些技术在没有测试时运行，总是选择能解除阻塞的最小侵入技术。
47. 把 Parameterize Constructor with production default 当作主力：现有 callers 不改也能编译，测试注入 fakes。
48. 把 Extract Interface 当作书中最安全动作：引入 interface 不会改变行为，只会放松类型。
49. 把 Subclass and Override Method 当作半个目录的基础：用 testing subclass 对危险部分打桩是合法工具，不是 hack。
50. 处理 statics 和 singletons 时，用 Introduce Instance Delegator 交给 callers 一个可替换实例；在测试中也可用 static setter 取代 singleton。
51. Adapt Parameter 优于与不可 fake 的 framework types 斗争：把 HttpServletRequest 包装成自己的窄接口，并针对它测试。
52. 动态语言有更便宜的 seams：unittest.mock.patch 或 jest.mock 可以代替多种技术，但 parameterizing 会留下更好的设计。
53. 构造函数打开 DB connection 时，用 Parameterize Constructor：def __init__(self, conn=None): self.conn = conn or connect()。
54. 到处调用 static Billing.charge() 时，用 Introduce Instance Delegator：实例 charge() 委托给 static，测试 override 它。
55. 900 行方法囤积 locals 时，用 Break Out Method Object：new RateCalculation(order, rates).run()，locals 变成 fields。
56. 在修改不理解的代码前，投资便宜的理解手段：effect sketches 追踪变更可能影响什么，feature sketches 显示 god class 内方法和字段如何聚类，scratch refactoring 随意重构以学习然后丢弃编辑，telling the story of the system 强制做简化总结。
57. 用 effect sketch：每个变量或方法一个 bubble，每个 affects 一条 arrow，从 change point 向前追踪到行为可能泄漏出的每个地方。
58. 寻找 pinch point：effect sketch 中的收窄处；在那里测试，其上游所有内容都被覆盖。
59. 把 scratch refactoring 当作阅读技术：extract、rename、simplify 一小时，然后 revert；洞察会在 checkout 后保留。
60. 处理 monster method 的策略：在 pinch point 做 golden-master，Break Out Method Object，然后在新类内部重构。
61. 处理 god class 的策略：先 feature-sketch 聚类，再沿它们之间的自然边界 extract。
62. 没时间时做 triage：只改一次的地方用 sprout 或 wrap；同一地方再次变更就有资格写测试。
63. 面对“改这个 field 会破坏什么？”时，从 field 向外画 effect sketch；找到 readers 后，用少量 pinch-point tests 覆盖它们。
64. 面对 5,000 行类里要交付 feature 时，先写 pinch-point tests，再 sprout；覆盖 postInvoice()，把新规则 sprout 成类。
65. 面对团队没人理解的代码时，在 branch 上 scratch refactor：extract 和 rename 以学习，revert，然后计划真正的动作。
66. 避免在同一步骤中重构和改变行为；修复方式：分开 commits，每步之间测试变绿。
67. 避免在 legacy code 上写 should tests；修复方式：characterize 代码实际行为，bug 单独 file。
68. 避免 mock 眼前一切；修复方式：只 fake 那些阻塞 instantiation 或 sensing 的东西。
69. 避免 big-bang rewrite 替代增量覆盖；修复方式：cover and modify，一块一块来。
70. 避免静默修复 characterizing 时发现的 bug；修复方式：pin 它、记录它，作为单独的、有意的变更修复。
71. 避免在任何测试存在前做侵入式 cleanup；修复方式：用最小侵入技术，保持签名，依赖编译器。
72. 避免永远 sprout 而不偿还；修复方式：跟踪 sprout debt，下次 touch 热点时覆盖。
73. 避免等待专门的 testing project；修复方式：沿每次交付的变更增长覆盖。
74. 做快速诊断：如果测试未覆盖你即将修改的代码，就运行 change algorithm，并在编辑前 pin behavior。
75. 如果无法在测试 harness 中构造类，用 Parameterize Constructor、Extract Interface 或 Sprout Class。
76. 如果测试无法感知变更效果，找 sensing point；用 Extract and Override Getter。
77. 如果 commit 不是 behavior-only 或 structure-only，就拆分它，并在两步之间运行测试。
78. 如果你不知道这次变更会影响的一切，画 effect sketch，并在 pinch points 测试。
79. 如果你的断言没有陈述观察到的行为，就 probe、读失败信息、pin 实际值。
80. 如果你选的 seam 不是可用的最便宜 seam，优先 constructor parameters 和 import seams。
81. 如果变更后代码不会得到更好覆盖，至少在最近的 test point 留一个 pin test。

适用边界 · 注意事项

• 代码已经有测试且只是常规重构时，不用本技能，改用 refactoring-patterns。
• 日常代码质量/clean code 问题，不用本技能，改用 clean-code。
• 计划进行 big-bang rewrite 而不是增量补测和逐步修改时，不适用。