好吧。实际上不是，但我曾在最初开发 QuickCheck 的人手下学习过，他是一个非常有趣的人。
早在 2004 年，我们被迫使用 QuickCheck 来测试我们的 Haskell 程序，它是好是坏的结合。主要是糟糕，因为 Haskell 本身有点令人畏惧，但当你让它工作时，仍然很棒。
从那时起，约翰完善了他多年前编写的代码，并实际上帮助爱立信测试了他们复杂的电信硬件，他发现了大约 2000 万行代码中的错误，通过他的方法将其减少到仅仅三个步骤。他是一位出色的演讲者，所以听他展示他的出色表现总是一件令人高兴的事情，但总而言之，他对 QuickCheck 所做的事情对我来说是新的。所以我问他，他对将其推向市场有何兴趣。他对这个想法持开放态度，但当时他的业务（基于 QuickCheck）相对较新，因此他还会关注其他领域。现在是 2007 年。我的观点是，即使您最终不会使用 QuickCheck，您也可以从它中学习。
但什么是快速检查？它是一个组合测试框架和一种有趣的测试程序的方法。微软研究院的人们已经建立了Pex http://research.microsoft.com/en-us/projects/Pex/这有点相似。 Pex 通过检查您的 IL 自动生成测试。然而，约翰会为函数的可能输入和测试属性编写一个生成器。属性是可以轻松测试的东西，而且更加正式。例如反转列表？嗯，反转列表与将列表分成两半，分别反转它们，然后以相反的顺序连接反转的两半是一样的。
1,2,3,4 // original
1,2 3,4 // split into A and B
2,1 4,3 // reverse A and B
4,3,2,1 // concat B and A
这是一个很好的属性，可以使用称为规范的 QuickCheck 进行测试，结果非常令人惊讶。
Pex 很好，但不如 QuickCheck 那么酷，Pex 简化了事情，QuickCheck 做到了，但编写好的规范需要付出很多努力。
QuickCheck 的强大之处在于，当它遇到故障时，它会将导致测试失败的输入减少到尽可能小的形式。为您提供导致测试失败的状态进展的详细描述。与其他测试框架相比，其他测试框架只会尝试以暴力方式破坏您的代码。
这是由于您如何编写测试规范而成为可能的。 QuickCheck 依靠伪随机性来发明输入，正因为如此，它能够回溯并找到未通过测试的非常小的输入。
编写 QuickCheck 属性需要做很多工作，但最终结果是更好的测试。正如 John 本人所说，70% 的错误是通过单元测试发现的，但正是另外 30% 的错误导致了程序崩溃。 QuickCheck 正在测试最后 30%。
