2085 个测试，却无一能阻止部署
2,085 Tests, and None of Them Opens the Front Door
我花了一整天阅读自己维护的 22 个仓库，发现了 2,085 个测试用例。然而，这些测试中只有一个仓库在持续集成中运行，零个在预提交钩子中执行。我拥有大量断言来描述软件行为，但几乎无法阻止糟糕的部署。问题不在于覆盖率，而在于测试与部署流程的脱节。我的测试擅长检查源代码不变量和序列化对象，却完全无法覆盖浏览器会话、多租户路由和真实登录流程等系统级问题。真正的缺口不是代码覆盖，而是将测试与部署连接起来的‘接线’。
问题不在于覆盖率，而在于测试与部署之间缺乏连接。
- perrygeo
讲个亲身经历：我曾和一个资深开发者共事，他极度推崇单元测试，而且只写单元测试。他要求软件必须像微小的乐高积木一样被彻底测试，到处都用 Mock。他的原话是：“如果每个部件都正确，组合起来肯定也正确”。（我想他从未考虑过“涌现行为”吧）
我永远不会忘记那个循环：在坚决反对集成测试、E2E 测试和手动测试，并狂热地坚持 100% 单元测试覆盖率之后，这位资深开发者部署了变更……boom。流程在启动几分钟后就彻底失败了，因为 main 函数里有个 Bug。直接导致生产环境全面宕机。这个 Bug 明显到肉眼就能看出来。显然，在开发该功能的几周里，他连运行一下应用都懒得做。每个部分在隔离状态下都打磨得完美无缺，但一旦集成到应用中就彻底崩盘。
我现在是这样理解的：单元测试是给库用的，那是一个封闭世界，你可以清晰地定义所有输入和输出。而集成/E2E 测试是给应用用的，那是一个开放世界，需要系统思维，需要的是模拟而非证明。搞清楚你身处哪个世界！
- KenPainter
你的网站似乎在搞乱浏览器历史记录。点击后退按钮无法返回 HN。
- netsharc
快速扫了一遍。其中一个小标题是“问题从来不是覆盖率，而是连线”。闻起来很有 AI 生成的廉价感，懒得细读了……
我以前在 HN 上什么都看，但现在我对这种“垃圾内容”过敏，已经不再这样做了。我想这算是一件好事吧？