我喜欢测试，因为它是一个快速的编程反馈回路在过去的二十多年里，我看到他们从偶尔的关键验证变成了现代系统设计的基本组成部分。
为什么关心快速测试？
当我写代码时，特别是在进行测试驱动开发时，我希望得到最快的反馈。这意味着快速测试。
我发现100ms是我认为任何单个测试足够快的上限。这仍然是令人痛苦的慢，但只是慢而已。
如果再慢于100毫秒，我发现从调用测试到注意到测试结果之间的延迟就会产生足够的停顿摩擦，以至于我--甚至不自觉地--开始回避运行测试。我会花更多的时间来写我认为正确的代码，而不是简单地让测试给我一个甜蜜的绿色确认。我在写新的测试之间会花更多的时间，并且开始在没有任何护栏或指导的情况下写出代码。
如果我在一个代码库中，单元测试套件需要几秒钟或（喘气）几分钟才能完成，我很快就会主张删除这种痛苦的无用的测试。
要清楚的是，我说的是单元测试，而不是集成测试。集成测试可以要求一个实际的数据库实际采取数据，并通过实际将其写入一些结构，无论是在内存中，在磁盘上，或（更糟糕的是）在一个远程机器上，来实际存储它。这些测试对其速度有真正的限制，这取决于你愿意在多大程度上隔离它们，并且仍然认为它们是有用的。
但是单元测试：没有网络，没有服务。只有潜在的生产代码和测试代码调用生产代码并对结果进行断言的纯洁性。
他们能走多快？
他们应该多快？
理想情况下，单元测试的运行时间应该小于10ms，最多100ms。
如果你的语言或测试框架不允许运行单独的单元测试，那么整个单元测试套件应该在1000ms（1秒）以内运行。
如果你使用任何广泛的通用编程语言，这完全是可能的，即使是有成千上万个测试的测试套件。计算机是快速的!
这怎么可能呢？
一个测试不是一个单元测试，如果。
- 它与数据库对话
- 它在网络上进行通信
- 触及文件系统
- 它不能与其他单元测试同时运行
- 你必须对你的环境做一些特殊的事情（如编辑配置文件）来运行它。
最快的测试是多快？理论上？
有一个绝对可能的最快测试速度。如果我们把自己从所有的硬件和软件的束缚中解放出来，那么我们最快的测试有可能有一个基本的速度限制。
这个速度限制就是--当然--光速。
没有信息能比光速更快。无论我们如何优化、改进、调整和精简，我们都无法摆脱信息从人到机器再到人的往返的限制。信息从根本上有一个速度限制。
- 我们需要告诉我们的系统去运行一个测试
- 我们的系统需要传输测试的结果
根据光速，这可以有多快？显然是非常快的，除非我们的计算机离得很远。
让我们假设我们的电脑在两英尺以外。我们的测试反馈能有多快？
两英尺的距离意味着我们的信号和反应需要走四英尺。（当然，光要在机器和我们自己的脑袋里传播，但让我们把这些距离放在一边）。
为了WolframAlpha
lightspeed / 4 feet = 4.067ns (nanoseconds)
这是一个有趣的数学怪圈，光走一英尺只需要一纳秒，这使得用过时的英制单位来衡量光速在人类范围内的距离相对容易。
4秒有多快？让我们深入了解一下时间单位吧!
1 second = 1 second (1 s)
1 second / 1000 = 1 millisecond (1 ms)
1 millisecond / 1000 = 1 microsecond (1 µs)
1 microsecond / 1000 = 1 nanosecond (1 ns)
只有几个数量级，没问题!
与我们一个单位测试10ms的合理情况相比？在连续运行一千个10ms单元测试的时间里，我们可以运行250万个最快的4ns测试。
可以说，我们永远不会达到这个速度，也不会对单个测试进行任何有意义的计算。但有目标是好的。
