变异测试:Quis Custodiet Ipsos Custodes
当测试驱动开发(TDD)成为一种“事物”时，很容易看到测试用例如何验证生产代码的功能，但明显的问题是如何确保测试用例的有效性。TDD是否会导致一个镜子般的大厅，有无数的测试用例套件来验证它们之前的套件?
当时，一个常见的答案是将TDD(或通常的单元测试)与复式记账法联系起来:每笔交易都记录在两个账户中，一个作为借方，另一个作为贷方，金额相同。如果到最后一切都平衡了，我们就没事了。类似地，测试用例保护生产代码，而生产代码保护测试用例。
这比我们在学习TDD之前所做的事情好多了，但仍然存在一个问题:人们并不擅长创建覆盖所有突发事件的测试套件。即使人们是完美的是，一些软件系统的复杂性使得它不切实际，甚至在经济上也是不明智的试一试并在测试用例中指定每个偶然性。
我们还能做什么?一种选择是基于属性的测试(PBT)。我以前查过PBT分享我的经历在这里。您的结论可能不同，但我发现PBT工具使用起来相当复杂，在某种程度上，所涉及的努力和时间并不值得所获得的好处，除非在某些情况下。除此之外，PBT并没有解决测试套件不完整的问题。
另一个选择是基因突变检测．使用突变测试，应用程序代码将以特定的方式进行修改，以引入错误，并针对修改后的应用程序执行现有的测试套件(基于示例的、基于属性的，或者其他)。调用修改后的应用程序代码块突变体．如果现有的测试套件捕捉到错误，则称为突变体杀了．如果测试套件没有注意到这个错误，那么突变体就被称为生存．
突变测试验证您的测试套件确实告诉了您您认为(或希望)的关于应用程序代码的信息。根据结果，您可以决定添加更多的测试用例或忽略一些幸存的突变，这取决于什么在上下文中有意义。
大多数主流语言都可以使用突变测试工具。他们中的大多数还不是很成熟。一个相当成熟的例子是坑， Java的突变测试工具。让我们试一试。
我碰巧有一个Java应用程序，它是我专门为测试工具而创建的，叫做Java扑克．恕我谦虚，我必须说我编写了不完美的代码，这是值得称赞的。让我们假装不完美是故意的，为了我脆弱的自我。
无论有意与否，如果一切都是100%正确的，那么代码库对于学习测试工具就没有多大用处。PIT应该在测试中发现相当多的改进机会。
后,快速入门我在Maven pom上添加了一个依赖项，并运行目标:
mvn org.pitest: pitest-maven: mutationCoverage
这是开箱即用的，没有定制，没有配置，没有目标代码库的准备，也没有对现有测试套件的修改。
PIT将各种类型的突变应用到代码中，并执行现有的测试套件。它生成了一个结果的HTML报告:
报告显示行覆盖率，这与突变无关，而且突变的报道，它告诉我们现有的测试套件检测通过突变注入的缺陷有多好。我们可以看到在这种情况下有许多突变存活了下来，这表明测试套件中有潜在的改进。
我们可以通过多个层次的报告来查看细节。在FiveCardStudGame类的这个例子中，PIT在几个地方发现“没有覆盖”。结果如下所示:
下面是AbstractCard类中的一个示例，展示了PIT如何报告幸存的突变:
该工具提供了足够的信息，说明它如何改变代码，以及发生了什么，以便您可以添加或修改测试用例来覆盖这种情况。
针对其他语言的突变测试工具提供了类似的信息。没有办法保证代码是完美的，但突变测试似乎是一种有用的技术，可以添加到您的工具包中，以提高对代码的信心。我发现这个特殊的突变测试工具非常容易使用，并且提供了很好的价值。