使用maven和jenkins，如何测试程序员做了一些测试用例？

Question

我正在开发一些项目，我们正在使用Java，Springs，Maven和Jenkins进行CI，但我遇到的问题是一些程序员没有向项目中添加真正的junit测试用例。我希望maven和jenkins在部署到服务器之前运行测试。一些程序员进行了空白测试，因此它开始和停止并将通过测试。

有人可以告诉我如何自动执行此检查，以便maven和jenkins可以查看测试是否输出了一些输出。

Answer 1

除了查看代码之外，我还没有找到任何解决此问题的好方法。

代码覆盖率未能检测到the worst unit tests I ever saw

查看测试次数，也失败了。查看测试名称，您打赌失败。

如果你有开发人员喜欢＆＃34; Kevin＆＃34;谁编写了类似的测试，你只能通过代码审查来捕获这些测试。

＆＃34; Kevin＆＃34;打败支票：

• 编写一个名为smokes的测试。在此测试中，您将使用不同的参数组合调用所测试类的每个方法，每个调用都包含在try { ... } catch (Throwable t) {/* ignore */}中。这为您提供了很好的覆盖范围，测试永远不会失败

• 写一堆空测试，其名称听起来像是您想到的花哨的测试场景，例如widgetsTurnRedWhenFlangeIsOff，widgetsCounterrotateIfFangeGreaterThan50。这些都是空的测试，所以永远不会失败，经理检查CI系统会看到很多详细的测试用例。

代码审查是捕捉凯文＆＃34;。

的唯一途径

希望你的开发人员不那么糟糕

更新

今天早上我洗了个澡。有一种类型的自动分析可以捕获凯文＆＃34;不幸的是它仍然可以被欺骗，所以虽然它不是人们编写错误测试的解决方案，但它确实使得编写错误测试更加困难。

Mutation Testing

这是一个旧项目，并且不能使用最近的代码，我不建议你使用它。但我建议它暗示一种自动分析会停止＆＃34;凯文＆＃34;

如果我实现这个，我会做的是写一个＆＃34; JestingClassLoader＆＃34;例如，使用例如ASM，用一点点＆＃34; jest＆＃34;重写字节码。一次。然后在加载此类加载器时针对您的类运行测试套件。如果测试没有失败，那么你就是＆＃34; Kevin＆＃34;土地。问题是您需要针对代码中的每个分支点运行所有测试。但是，您可以使用自动覆盖率分析和测试时间分析来加快速度。换句话说，你知道每个测试执行的代码路径，所以当你做一个＆＃34; jest＆＃34;对于一个特定的路径，您只运行命中该路径的测试，并从最快的测试开始。如果这些测试都没有失败，那么您发现测试覆盖率存在缺陷。

所以如果有人要现代化＆＃34;小丑，你有办法找到＆＃34;凯文＆＃34;进行。

但这不会阻止人们写错误的测试。因为您可以通过编写测试来传递该检查，该测试验证代码的行为与目前的行为，错误和所有行为。哎呀甚至有销售软件的公司会为你写＃34;。我不会通过链接到他们来给他们谷歌网页排名，但我的观点是，如果他们得到这样的软件，你将有大量的测试，直接夹克你的代码库，并没有发现任何错误（因为一旦你改变任何东西，生成的测试就会失败，所以现在做出改变需要争论改变本身以及改变所破坏的所有单元测试的变化，增加了业务成本进行更改，即使该更改正在修复真正的错误）

Answer 2

我建议使用Sonar，它有一个非常有用的build breaker插件。

在声纳quality profile内，您可以对metrics的任意组合设置提醒，例如，您可以强制要求您的Java项目

• “单元测试”＆gt; 1
• “覆盖范围”＆gt; 20

强制开发人员至少进行一次单元测试，覆盖至少20％的代码库。 （相当低质量的酒吧，但我想这是你的观点！）

设置其他服务器可能看起来像额外的工作，但是当您有多个Maven项目时，解决方案会扩展。 Sonar的Jenkins plugin就是您需要配置的全部内容。 Jacoco是默认的代码覆盖工具，Sonar还会自动运行Checkstyle，PMD和Findbugs等其他工具。

最后Stephen对代码审查完全正确。 Sonar有一些基本但有用的代码审查功能。

Answer 3

您需要添加代码覆盖率插件，例如JaCoCo，EMMA，Cobertura等。然后，您需要在插件的配置中定义您希望拥有的代码覆盖率（基本上是“测试所涵盖的代码”）的百分比，以便构建通过。如果低于该数字，则可能导致构建失败。而且，如果构建失败，Jenkins（或任何你的CI）将不会部署。

Answer 4

正如其他人所指出的那样，如果您的程序员已经开始欺骗编码实践，那么使用更好的覆盖工具将无法解决您的问题。他们也可能被骗了。

您需要与您的团队坐下来，与他们诚实地谈论专业性和软件工程应该是什么。

根据我的经验，代码审查很棒但是它们需要在提交代码之前发生。但是，为了在人们“作弊”的项目中工作，你至少需要一个你可以信任的评论家。

Answer 5

http://pitest.org/是一个很好的解决方案，用于所谓的变异测试＆＃34;：

  

故障（或突变）会自动播种到您的代码中，然后运行您的测试。如果您的测试失败，那么突变就会被杀死，如果您的测试通过，那么突变就会存在。

     

您的测试质量可以通过杀死突变的百分比来衡量。

好处是你可以将它与maven，jenkins和...... SonarQube结合使用！