对测试失去信心

测试与设计的作用

• 许多人认为，测试无法拯救根本糟糕的架构；简化和可理解性更重要。
• 也有人报告称，使用集成测试先把遗留的乱摊子“包起来”，再安全地重构它取得了成功；他们把测试视为简化的助力，而不是替代品。
• 测试被描述为一种用于建立信心和推动变更的工具，而不是正确性的保证。

测试何时价值很高

• 核心、稳定、承重的组件（VM、数据库、核心业务逻辑）从广泛的测试和模糊测试中获益巨大。
• 集成测试和端到端测试因能捕捉真实的跨系统错误、并支持无惧重构而受到赞赏，尤其是在多服务和基础设施密集型系统中。
• 测试在升级库/框架、防止回归、以及在原作者离开后保留行为方面很有价值。
• 属性测试和强大的测试套件被视为成熟系统的“实战加固”。

测试何时被视为低回报

• 初创公司里快速变化的产品功能和 UI 打磨，可能被过度测试，扼杀迭代速度，并导致脆弱、不断失败的测试套件。
• 交互式工具（文本编辑器、终端）如果主要路径会在实际使用中被持续运行，可能就不需要那么多自动化测试。
• 一些团队表示，他们在几乎没有自动化的情况下也能交付可接受的产品，依靠手动测试、指标、金丝雀发布和回滚。

文化与流程问题

• 测试常常被当成一种宗教：覆盖率目标、TDD 教条、以及“每一行都必须有测试”的强制要求，会产出低价值、依赖 mock 很多的测试套件。
• 古德哈特定律：把覆盖率当作 KPI，会导致产生琐碎或重复的测试，这些测试并不能提升质量，反而拖慢变更。
• 激励机制（工单吞吐量、缺乏时间）会把开发者推向“拼凑出来的烂东西”；因此，责怪个人而不是系统的做法受到批评。

替代方案、补充与策略

• 强类型系统消除了许多类别的 bug，并减少了所需测试，但不能取代测试；类型和测试被视为互补。
• 手工探索式测试仍被认为对于 UX 问题、性能意外以及未预见的交互至关重要。
• 一些评论者主张把测试视为投资：聚焦高价值场景、核心不变量和回归保护；让测试套件保持快速、低抖动，并愿意删除或避免低回报测试。