不敢改老代码？用测试给重构上保险
面对一段多年前写的、没人敢动的老代码，你想重构又不敢下手，因为没人知道改动会连带影响哪些功能。这种恐惧的根源，不是代码难，而是缺少一张能告诉你有没有改坏的安全网——测试。
测试为什么是重构的前提
重构的定义是：在不改变外部行为的前提下改善内部结构。问题在于，你凭什么确认行为没变？一套能自动运行的测试，就是那个裁判。有它，改代码像换零件；没它，改代码像拆炸弹。这也解释了为什么很多人嘴上同意重构，身体却很诚实——不是不想，是不敢。
红绿重构：用测试驱动设计
- 红：先写一个会失败的测试，明确你要实现什么。
- 绿：写最少的代码让测试通过，先别追求优雅。
- 重构：在测试的保护下优化结构，随时可回退。
这套循环的深层价值在于：先写测试意味着你从调用方的角度使用接口，会自然逼出更友好的设计。而且小步快跑，每次只改一点，问题立刻暴露，远比改完两百行再调试轻松。
测试怎么写才算合格
记住FIRST原则：快速、独立、可重复、自我验证、及时。此外要分清层次：单元测试负责复杂逻辑的细粒度验证，集成测试只做简单的连通性检查。把复杂用例塞进集成测试，会让整条流水线又慢又脆。
给老代码补测试的实用策略
遗留代码无处下手时，可以用描述性测试先给现状拍照：不评判代码对不对，只把当前实际输出记录下来。这样你就有了一个基线，一旦重构后行为变化，测试立刻报警。之后每修复一个Bug，都补一条对应测试，用真实缺陷喂养测试集，覆盖率会自然长起来。
一个真实场景
一个团队的计费模块逻辑混乱，谁都不敢碰。他们先做了两件事：用测试把现有规则的实际计算结果固化下来，再把单元测试拆细补全。有了这层保护，两个月内他们完成了一次较大重构，上线后零事故。不是代码突然变好懂了，而是终于有了敢动手的底气。
常见误区
- 为了覆盖率而写测试：只测没有断言的空壳，等于没有保护。
- 测试依赖外部环境：连数据库、网络一起测，又慢又不稳定，没人愿意跑。
- 先写完代码再补测试：补出来的往往迁就实现，测不出问题。
- 一次重构改太多：改动越大，测试变红越难定位。小步前进。
行动建议
下次遇到老代码，别急着动手改。先为它写一个描述当前行为的测试，跑一遍，看着它通过。这一步不产出新功能，却给后续所有改动装上了刹车和安全带。