项目上线前突然冒出一堆 bug，开发改得焦头烂额，测试反复回归，团队加班成常态。这种情况并不少见，根源之一就是缺少有效的代码质量保障机制。单元测试不是新鲜事，但在实际团队中推行起来却常常“雷声大、雨点小”。怎么让单元测试真正落地？这需要的不只是技术，更是一套行之有效的推进策略。
从痛点切入，别一上来就讲道理
直接开会宣布“我们要写单元测试”，大概率会被当成又一个形式主义任务。更好的方式是抓住团队正在经历的痛点。比如某次紧急修复引发的连环问题，可以拿出来复盘：“如果这个核心方法有测试覆盖，是不是就能早点发现问题？”用真实场景说话，比讲一堆“好处”更有说服力。
先做“最小可行测试”，降低启动门槛
很多开发者抗拒写测试，是因为觉得太麻烦。这时候不要追求覆盖率 80% 甚至 100%，先从最关键的模块入手。比如用户登录逻辑、金额计算这类一旦出错后果严重的功能，补上几个基础测试用例。哪怕只有两三条，也能在下次修改时提供基本保护。
以 Java 为例，一个简单的加法工具类测试可以这样开始：
public class CalculatorTest {
@Test
public void should_return_sum_of_two_numbers() {
int result = Calculator.add(2, 3);
assertEquals(5, result);
}
}把测试变成提交代码的“通行证”
光靠自觉很难持久。可以在 Git 提交流程中加入检查，比如通过 CI 工具（如 Jenkins、GitHub Actions）设置：没有对应测试代码的 MR（合并请求），自动标记为不通过。一开始可以宽松些，只对新增核心代码要求测试覆盖，逐步收紧规则，让大家适应节奏。
老手带新手，形成正向循环
找一两个对质量敏感、愿意尝试的同事先动手。他们写出来的测试用例可以作为模板，在代码评审时展示：“你看，这个边界情况被测出来了，避免了潜在 bug。”其他人看到实际价值，自然会跟进。偶尔组织一次“测试 Pair Programming”，两人一起给一段旧代码补测试，边做边聊，比培训课更有效。
别追求完美，先跑起来再说
有些团队卡在“测试怎么写才规范”上迟迟不动。其实初期写的测试可能不够优雅，命名不清、覆盖不全，都没关系。关键是先把习惯建立起来。就像学骑自行车，一开始摇摇晃晃，但只要动起来，后续优化才有基础。等大家普遍写起来了，再通过评审慢慢引导改进风格。
让测试成为团队的“安全网”而不是“负担”
当某次重构后，测试自动发现了问题，及时避免了线上故障，一定要提一句：“多亏了那个测试，不然又得背锅。”这种正反馈会让团队意识到，测试不是增加工作量，而是减少救火时间的利器。慢慢地，写测试会从“被要求”变成“我需要”。
推行单元测试，本质上是推动一种工程文化的转变。技术只是工具，关键在于如何让人愿意用起来。从实际问题出发，小步快跑，用结果赢得信任，才是可持续的做法。