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

Question

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

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

Answer 1

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

代码覆盖率无法检测到我见过的最糟糕的单元测试

看一下测试的数量，那里也失败了。 查看测试名称，您打赌失败。

如果您的开发人员喜欢编写类似测试的“Kevin”，那么您只能通过代码审查来捕获这些测试。

“凯文”如何击败支票的摘要：

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

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

代码审查是捕获“凯文”的唯一方法。

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

更新

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

变异测试

这是一个旧项目，不适用于最近的代码，我不建议你使用它。 但我建议它暗示一种自动分析会阻止“凯文”

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

因此，如果有人要让Jester“现代化”，你就有办法找到“凯文”了。

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

Answer 2

我建议使用Sonar ，它有一个非常有用的构建断路器插件。

在Sonar 质量配置文件中，您可以针对任何指标组合设置警报，例如，您可以强制要求您的Java项目应该具有

• “单元测试”> 1
• “覆盖范围”> 20

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

http://pitest.org/是所谓的“突变测试”的一个很好的解决方案：

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

您可以根据已杀死的突变百分比来衡量您的测试质量。

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