在敏捷开发已几乎成为行业默认范式的今天，单元测试却被逐渐推向一个极端两极化的境地。支持者将其奉为代码质量的守护神，认为没有单元测试的代码库就是一盘散沙；反对者则指责它消耗了海量时间，却常常沦为重构时的负担、或仅仅为了覆盖率指标而存在的形式主义。这种撕裂并非源于工具差异，而是因为我们长期将单元测试视为一种“检验手段”，而非一种“沟通机制”。当我们在讨论单元测试时，真正讨论的其实是“可测试性”与“未来改动成本”之间的博弈。因此，我们需要抛弃非黑即白的判断，重新审视在持续交付与AI辅助编码加速出现的当下，单元测试究竟承担着什么不可替代的角色，又该把边界划在哪里。
对单元测试最经典的指责，是它“锁死了实现细节”。批评者常举这种例子：一个简单的getter或一个内部算法，单元测试将它们与特定输入输出绑定，一旦内部优化或调整，测试就会碎一地。这其实混淆了“脆弱测试”与“有效测试”的区别。真正健康的单元测试，应该测试行为契约，而非测试函数内部的一行行代码。比如，对排序函数，你关心的是任意输入能返回正确的顺序，而绝不是强制要求它必须使用快速排序。对比集成测试，集成测试确实能捕捉模块间协作的断裂，但它的失败定位极其模糊，往往在两周后才发现最底层的某条逻辑早已悄悄变化。更深远的意义在于，单元测试是最低成本的结构化文档——它能即时展示一个类的职责边界和预期行为，这种文档永远不会和代码脱节，因为任何脱节都意味着测试失败。
不过，我们必须承认，单元测试在业务逻辑简单或一次性探索性项目中，确实可能带来负收益。那种必须依赖大量Mock才能跑通的单元测试，本质上已经不是在测试真实行为，而是在测试Mock库自身的表现。这种测试不仅维护成本高，而且会严重拖慢重构进程，让开发者陷入“为了保住绿灯而不敢动代码”的僵局。对比之下，面向领域模型的纯函数式单元测试则极其廉价且稳定。这要求架构本身必须向“依赖抽象”与“副作用隔离”倾斜。所以，单元测试的好坏，从来不是由“测试的数量”决定的，而是由“被测试代码的设计质量”决定的。当一个模块很难被单测时，这本身就是对架构的最强烈警报——你的依赖过于具体、边界过于模糊、职责过于混杂。从这个角度看，单元测试更像是一名严格的架构评审员，而不是一道质量护栏。
身处当下，当我们面对AI生成的代码越来越多，单元测试的价值反而被重新激活。AI可以快速生成实现，但无法替代人类去定义清晰的行为规范。盲目信任AI代码会导致系统行为逐渐漂移，而一套真正的好单元测试则成为行为契约的锚点——我们不用关心AI采用何种算法，只要它满足既定输入输出和异常契约，就可以放心集成。与此同时，AI也能反向赋能单元测试：它可以根据函数签名和自然语言描述生成初始用例，让测试覆盖那些人类容易遗漏的边界情况，这大幅降低了编写测试的成本门槛。因此，未来的单元测试并不会消失，而是会从“事后的验证”转化为“左右的规范设计”。它不再是固定阶段必须完成的任务，而是贯穿开发全生命周期的行为定义语言。
最终，我们需要重新界定单元测试的边界：无论是单元测试、集成测试还是端到端测试，它们服务于同一个目标——在不确定的代码演进中保持可预测性。单元测试适用于核心算法、状态机、数据处理规则和数学计算等行为明确且逻辑复杂的场景；而对于UI动态交互、或高度依赖外部基础设施的胶水层，则应果断放弃单元测试，采用更粗粒度的测试覆盖。我们必须承认，没有任何一种测试策略能独立支撑系统质量，单元测试也不例外。但它拥有的独特优势——快速反馈、精准定位、设计反哺、及作为与AI交互的“契约语言”——使它在复杂软件生态中依然是一块不可替代的基石。理性看待它的优点与局限，并配合语境灵活运用，比盲目追捧或彻底放弃，都更需要专业智慧。未来十年，单元测试不会因AI而死亡，反而会进化成一种更高级的“行为规范”系统——就像数学公理一样，真实、简洁、无法绕过。
