好吧。其实没有，但是我是在最初开发QuickCheck的那个人的带领下学习的，他是一个非常有趣的人。
早在2004年，我们就不得不使用QuickCheck来测试我们的Haskell程序，这是好事与坏事的结合。主要是因为Haskell有点令人生畏，但当您开始工作时，它的精彩程度从未如此出色。
从那时起，John完善了自己多年编写的内容，并实际上帮助Ericssion测试了其复杂的电信硬件，并且他在2000万左右的代码行中发现了错误，通过他的方法，将其减少到仅三个步骤。他是一位出色的演讲者，所以听他介绍他的出色表现总是很高兴，但总而言之，他对QuickCheck所做的一切对我来说都是新的。所以我问他，他的兴趣是什么将其推向市场。他对这个想法持开放态度，但是当时他的业务（基于QuickCheck）相对较新，因此他还需要关注其他领域。现在是2007年。我要说的是，即使您最终不会使用它，也可以向QuickCheck学习。
但是什么是QuickCheck？这是一个组合测试框架，是测试程序的一种有趣方式。微软研究院的人们已经建立了类似的Pex。Pex通过检查您的IL自动生成测试。但是，John会为函数的可能输入和测试属性编写生成器。属性是可以轻松测试的东西，它更加正式。例如倒转清单？好吧，反转列表与将列表分成两半，分别将它们分别反转然后以相反的顺序连接两个反转的一半相同。
1,2,3,4 // original1,2 3,4 // split into A and B2,1 4,3 // reverse A and B4,3,2,1 // concat B and A
这是使用QuickCheck测试的一个很棒的特性，称为规范，其结果令人惊讶。
Pex很不错，但是不像QuickCheck那样酷，Pex简化了事情，QuickCheck做到了，但是编写一个良好的规范需要大量的精力。
QuickCheck的功能在于，当它发生故障时，它将导致测试失败的输入减少到最小的形式。向您详细说明什么状态进展会导致测试失败。与其他测试框架相比，它们只是试图以蛮力方式破坏您的代码。
由于您编写测试规范的方式，这使之成为可能。QuickCheck依靠伪随机性来发明输入，正因为如此，它能够回溯并找到很小的输入而无法通过您的测试。
编写QuickCheck属性需要做很多工作，但是最终结果是更好的测试。就像约翰本人所说的那样，70％的错误是通过单元测试捕获的，而其他30％的错误则导致程序崩溃。QuickCheck正在测试最后30％的内容。
