​​

过去几年里，我一直在使用各种基于 NodeJS 的测试框架。这些框架包括 Mocha、Jasmine 和 Playwright。有趣的是——至少对我来说——这些框架往往有一些共同的模式和结构。虽然其中一些模式很好（例如默认使用配置文件），但有一个我实在讨厌的模式：实现一个全局测试超时，而且这个超时默认是开启的。

亲爱的读者，我不喜欢这个功能，一点都不喜欢。

这个想法其实很简单：设置一个超时值——比如说 30 秒——如果一次测试执行的总时间超过这个超时值，测试就会失败或者抛出一个错误，提示“您的测试运行时间已超过 30 秒”。在很多情况下，这个超时值默认是 30 到 60 秒左右。将这个功能配置成这样，简直是疯了。

测试框架的形态和规模各不相同，就像软件项目一样。有些框架是精简而高效的，只有少量相对快速的测试；而另一些则是庞大且缓慢的，测试代码也远非最佳。如果你正在为测试自动化创建一个框架，你应该预见到不同类型的项目可能会使用你的工具。对于某些项目，可能需要 30 秒来设置并连接到被测系统，而测试甚至在开始之前就会超时失败。

要记住软件中的默认值的力量，默认值可以极大地影响你的工具的工作方式。测试失败就是失败，无论是什么原因。如果失败的原因是几年前的某个团队成员决定 30 秒“太长了”而导致的，那可能会引发一些尴尬的对话。编码框架应该帮助你的团队工作，而不是成为绊脚石。仅仅因为测试运行时间超过了某个不明确的值而导致失败，这似乎违反了“最小惊讶”设计原则。

当然，也有一些情况可以禁用这个超时功能，但这让我不禁想为什么一开始要启用它呢？例如，在 Jasmine 中有一个 DEFAULT_TIMEOUT_INTERVAL​ 值，这是一个规范在超时并失败之前所能运行的最长时间。但为什么不默认禁用这个功能呢？一个任意的规范应该运行多长时间？这是一个完全基于上下文的开放性问题。这些问题和讨论本可以通过不启用这个功能来避免。

我必须承认，全局测试超时在某些情况下确实有一些好的用例。在成熟的持续交付流水线中，超出某个运行时阈值的测试可以从流水线中移除并重新评估，但这需要其他的配套措施。全局超时也可以作为性能问题的粗略信号，但同样需要其他的检查和平衡机制来配合。

默认启用这种超时功能，并不会让我感到愉悦，我相信对于很多第一次使用 JS 测试的团队来说也是如此。