几年前一次技术面试中，一位CTO打断我并说：“我们不写测试，因为业务逻辑变化太快。”初听起来，初创公司需求频繁迭代，似乎有道理。但仔细想想，这个逻辑完全反了——变化恰恰是写测试的理由，而不是不写的借口。
如果软件几乎不变，弱测试覆盖还能勉强运转；可业务逻辑每周都在变，你不断触碰生产环境运行的代码，风险会不断累积。测试最大的价值不是抓bug，而是让你在修改现有代码时有东西可依赖。想象一下要更新一年前上线的定价规则：新的条件本身很简单，但真正难的是找出这个行为在其他地方还有哪些依赖——另一个结算流程、某个市场两年前添加的覆盖、某个仍在运行的旧活动。没有测试，你只能手动检查几个场景，靠产品和老同事的记忆来验证。随着系统变大，手动测试变成了“希望大家都记得对的事情”。
软件永远不会真正完成：业务规则变、用户行为出乎意料、性能问题、法规演进。有时一个小需求会暴露多年积累的设计问题——同一规则在四个地方重复、三个无关模块依赖同一个工作流、修一个边缘情况却影响到远超出预期的范围。这时缺乏测试的成本就显现了：团队用人工检查来补偿，但总会有被忽略的情况导致上线失败。发布变慢，越来越多的人介入，代码库某些区域变成“危险区”，所有人都知道该清理但没人敢碰。工程师可能很清楚设计的问题，甚至知道如何改进，但他们不相信自己动手后的结果。这就是短期技术债慢慢变成架构的原因——不是因为没人注意到，而是因为改变比维持现状更冒险。
有用的测试套件能改变这一点：它能给团队足够的反馈，让他们逐步改进系统，而不是等待一次可能永远不会发生的大重写。但这不等于测试越多越好——慢速或脆弱的套件会制造同样的不确定性；与实现过度耦合的测试会让无害的重构寸步难行。关键在于，测试应该保护业务依赖的行为，而不是每次内部结构变化时都崩溃。
这正是那句话让我一直记住的原因。不是因为他们不写测试，而是背后的逻辑：他们知道软件在持续变化，却没有给工程师更安全的方式去应对，而是把不确定性当作工作中理所当然的一部分。当这成为常态，人们最终会停止改进系统——避免重构、绕开糟糕设计、每次触碰旧代码都小心翼翼。我后来在两种系统都工作过：一种是小改动验证比实现还慢，因为没人知道会连带什么；另一种是更大的改动也能逐步推进，因为团队有足够的反馈。我们需要测试不是因为软件稳定，而是因为工程师需要信心去改变它。
#开发者 #工具 #软件工程 #测试 #技术债务 #重构 #工程文化
@DevToolboxHub