单元测试曾经是软件工程最耀眼的神坛。从敏捷运动到测试驱动开发，几乎每一本技术畅销书都在重复同一个咒语：每个方法都应该有独立的、快速、可重复的验证。于是，数百万开发者夜以继日地敲打着mock、stub、spy，用覆盖率数字来证明自己的代码“健康”。但当我们冷静审视那些拥有“完美”单元测试的系统时，却常常发现它们依然在集成环境中崩溃、在需求变更时呻吟、在重构时成为最沉重的锁链。这是一个悖论：我们越相信单元测试，它就越使我们失望。
我们究竟在做什么？传统的单元测试假设系统由无数孤立的零件组成，每个零件的正确性一旦验证，整机自然正确。然而真实的软件是复杂网络，接口间的交互、时序、状态转换、外部依赖的行为，恰恰是故障的高发地带。集成测试、契约测试和端到端测试虽然成本更高，但能覆盖这些边界。对比一下，单元测试平均需要为每个业务方法构造5到10个测试用例，却只能覆盖逻辑分支的70%；而一个精心设计的契约测试，用不到十分之一的代码量，就能锁定服务间最关键的协议兼容性。更可怕的是，单元测试过度依赖mock后，测试验证的其实是“模拟对象之间的剧本”，而不是真实世界的参数——这种自欺欺人的安全感，比没有测试更危险。
我的独立观点是：单元测试真正的价值不在于“保证质量”，而在于“驱动设计”。当你为一个复杂方法编写测试而感到痛苦时，那是一种信号——你的职责分离不正确、依赖过于隐晦、或抽象层次出了问题。测试的红色是设计师的警钟，而不是质量门的告警。反过来，如果团队把所有精力都用于提升单元测试覆盖率和追求虚无的“测试金字塔平衡”，他们就会失去对架构质量的敏感度。过度依赖单元测试会让代码变得“测试友好”而非“用户友好”——为了便于构造测试，开发者常常暴露内部状态、增加getter/setter、引入事件总线，甚至牺牲领域模型的封装性。最终，测试成为了代码的骨骼，而业务逻辑被压成一张薄皮。可悲的是，这种本末倒置的“测试导向设计”，正在无数企业级项目中被当成最佳实践。
如今，AI正在改写这场游戏。以GPT为代表的代码生成模型可以瞬间为任意函数生成数百个单元测试用例，甚至能自动发现边界值、构造异常数据。但这并非福音，反而会加速测试的“通货膨胀”。如果人类从写测试变成“审查AI生成的测试”，那么测试的意图性就彻底消失了——AI不会理解你的业务痛点，它只会优化代码覆盖率。此时，单元测试从设计工具沦落为纯事后验证，甚至只为满足合规指标。更前沿的思路是让AI直接分析生产日志、用户行为、故障模式，动态生成“行为契约”测试——那些真正能捕获回归、指向业务风险的测试。我们不需要一万个微小的断言，我们需要的是几十条高价值的行为规约。一个行为契约测试直接描述“当订单状态为已支付且库存不足时，系统必须发出缺货事件并回滚”，而不是“orderService.pay()的返回值是false”。
所以，我们必须勇敢地走下单元测试的神坛，重新分配资源。对于初创项目，少写单元测试，多写行为契约测试和轻量级集成测试，把精力投入到领域建模和架构演进上；对于成熟系统，用契约测试保护API边界，用快照测试捕获高风险UI状态，用AI预测故障热点并定向编写深度测试。单元测试应当被降级为“设计验证工具”，只在代码审查、重构辅助和教学场景中发挥价值。真正的质量不是由测试数量决定，而是由代码对变动的适应性和对业务错误的反馈速度决定。让我们从“为测试而测试”的迷信中醒来，把时间还给设计，把软件还给生活。