在主流技术话语中，单元测试几乎被塑造成一种道德义务——仿佛不写测试的开发者就是不负责任的工匠。但当我们拆开这层神圣外壳，会发现一个尴尬的事实：大多数团队对单元测试的信仰，不是基于数据，而是基于恐惧。恐惧回归缺陷、恐惧架构腐化、恐惧在评审中被质疑。这种恐惧催生了大量“仪式性测试”——它们能提升覆盖率数字，却无法提升系统可信度。实际上，单元测试的真正价值不在于验证代码是否工作，而在于压缩未来调试时的搜索空间。一个测试断言的是行为契约，而非实现细节。然而，绝大多数测试都在错误地锁定行为，把重构变成一场与自身测试的游击战。
我们必须正视单元测试的暗面：机会成本。每个测试都有维护成本、编译时间、CI排队时间，以及最重要的——认知税。当测试代码超过生产代码的复杂度时，它就不再是安全网，而是一张信息熵极低的迷宫地图。开发者需要同时维护两套心智模型：系统应该做什么，以及测试认为系统做了什么。这两者一旦分歧，测试便从守护者变为暴君。更深刻的问题在于，单元测试默认了“被测单元”是稳定且可隔离的，但在真实业务中，大多数价值来源于跨模块交互。过度依赖单测会导致一种“局部正确性幻觉”——每个齿轮都完美，但整个钟表不转。这解释了为什么许多团队拥有高覆盖率，线上故障依然如故。
跳出非黑即白的争论，我们需要的不是“要不要测”，而是“测什么、怎么测、测多深”。我提出“可变性原则”：单元测试的密度应该与代码的可变性成正比。稳定的基础库（如日期工具、金额计算）需要严格测试；而多变的编排类代码（如Controller、Workflow）应让位于集成测试和契约测试。同时，引入“测试异味”概念——断言内部状态、过度模拟、测试与实现强耦——这些气味比代码异味更致命，因为它们会悄悄冻结架构。一个独立的观点是：最好的测试是那些删除后需要大量重写的测试？不，恰好相反。最好的测试是那些在重构生产代码时仍然不变绿（即完全不受影响）的测试。它们才真正锁定行为而非实现。
最终，单元测试应被重新定义为一种“知识文档”而非“质量工具”。它的读者是未来的开发者，而非当前的覆盖率报告。当团队能把测试视为沟通设计约束的活文档，而非赎罪券，才能破除非理性的测试崇拜。我的建议是：采用“风险驱动测试四象限”——高可变性+高影响（核心规则）用单测+属性测试；高可变性+低影响（内部工具）用冒烟测试；低可变性+高影响（第三方适配）用契约测试；低可变性+低影响（样板代码）不写测试。这套体系放弃了“全测”的幻想，把有限认知资源投到最值得的地方。单元测试不是道德，它是决策。而一切不提成本的决策论都是耍流氓。
