问您是否在实际项目中使用过Quickcheck

EN

是的，好吧。实际上不是，但我曾师从于最初开发QuickCheck的人，他是一个非常有趣的人。

回到2004年，我们被迫使用QuickCheck来测试我们的Haskell程序，这是好的和坏的结合。大部分都很糟糕，因为Haskell本身有点令人望而生畏，但当你让它工作时，它仍然很棒。

从那时起，John完善了他几年前写的东西，实际上帮助爱立信测试了他们复杂的电信硬件，他在大约2000万行代码中发现了错误，通过他的方法将这一过程减少到了仅仅三步。他是一个伟大的演讲者，所以总是有一个joy在听他讲述他做得很好的东西，但总而言之，他和QuickCheck做的事情对我来说是新的。所以我问他，他对把这个推向市场有什么兴趣。他对这个想法持开放态度，但当时他的业务(基于QuickCheck)相对较新，因此他还会专注于其他领域。现在是2007年了。我的观点是，即使你最终不会使用QuickCheck，你也可以向它学习。

但是什么是QuickCheck呢？它是一个组合测试框架，也是一种有趣的测试程序的方法。微软研究院的人已经开发出了类似的Pex。Pex通过检查您的IL自动生成测试。然而，John会为可能的输入编写一个生成器，并测试函数的属性。属性是很容易测试的东西，而且它更正式。例如，反转列表？嗯，颠倒一个列表，等同于将一个列表一分为二，分别颠倒它们，然后以相反的顺序连接两个颠倒的一半。

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%的but是通过单元测试捕获的，但正是另外30%的but导致程序崩溃。QuickCheck正在测试最后30%的数据。

我做了一个真实的Haskell问题，其中包括离散事件模拟。因此，我编写了一个基于continuation的DES库，以及MVars和Channels的等价物。我需要检查这是否正常工作，所以我编写了一组QuickCheck属性来演示，例如，写入通道的两个并发数据流将被正确合并，而不会丢弃任何内容。

我还使用QuickCheck记录和验证了我的Ranged Sets和Decimal库中的属性。

根据我的经验，QuickCheck有时是很棒的。如果你能以一种简洁的方式总结一个重要的属性，尽管交付该属性的算法很复杂，那么QuickCheck是一个巨大的胜利。另一方面，我经常发现算法等同于我想要验证的属性。在这种情况下，我寻找更简单的属性。例如，假设函数"foo“是非严格单调的。然后你就可以写

prop_fooMonotonic x y = (x > y) ==> (foo x >= foo y)

我使用QuickCheck做很多私人的事情。在过去六个月内：

• 运行QuickCheck来测试图像中的颜色变换和离散余弦变换，以测试我为一些numerical QuickCheck开发的符号微分模块，以测试本特利和塞奇威克风格的三元搜索树。

QuickCheck很少能满足我所有的单元测试需求，但它是一种很好的入门方式-而且QuickCheck法则提供了很好的文档。