Java JUnit报告显示测试功能，而不是覆盖率

团队领导的问题之一是团队中的人（有时甚至包括我自己）经常在没有任何测试功能的情况下创建JUnit测试

这很容易做到，因为开发人员使用JUnit测试作为工具来启动他们正在编写的应用程序的一部分，然后有意或无意地将其签入，而不进行任何断言测试或模拟验证

后来，人们忘记了测试是不完整的，但是它们通过了测试，并产生了很好的代码覆盖率。运行应用程序并通过它提供数据将创建来自Cobertura或Jacoco的高代码覆盖率统计数据，但是除了它运行而不爆炸的能力之外，没有任何测试—我甚至看到在测试中使用了大的try-catch块

有没有一个报告工具可以测试测试，这样我就不需要经常检查测试代码了

通过更改测试中的代码（例如if子句）并重新运行它以查看它是否破坏了测试，我暂时很兴奋地找到了哪些测试

然而，这不是您可以设置在CI服务器上运行的东西-它需要在命令行上进行设置，不能在不显示GUI的情况下运行，只能将结果打印到GUI上，而且运行也需要一些时间。

是标准的Java变异测试仪。从他们的网站：

突变测试在概念上相当简单

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

传统的测试覆盖率（即行、语句、分支等）只测量测试执行的代码。它不会检查您的测试是否能够检测执行代码中的错误。因此，它只能识别肯定未测试的代码

这个问题最极端的例子是没有断言的测试。幸运的是，这些在大多数代码库中并不常见。更常见的是，代码只经过其套件的部分测试。仅部分测试代码的套件仍然可以执行其所有分支（示例）

由于它实际上能够检测每一条语句是否经过有意义的测试，突变测试是衡量所有其他类型覆盖率的金标准

检测的质量可以通过突变致死的百分比来衡量

它具有相应的功能，可以简化作为CI构建一部分的集成。我相信下一个版本也将包括与Maven站点报告的适当集成

---

此外，创建者/维护者在StackOverflow上非常活跃，并且善于回答标记的问题。

在实现功能或修复测试应该处理的错误之前，尽可能编写每个测试。功能或错误修复的顺序为：

写一个测试

运行它。在这一点上，如果它是一个好的测试，它将失败。如果有 不能失败、改变、替换或添加

当测试失败时，实现它应该具备的功能 测试。现在应该过去了

---

听起来你需要考虑一个覆盖工具，比如提供覆盖的报告。我还使用Eclipse插件来获得相同的结果，但是在IDE中有一个相当好的集成

根据我的经验，即使没有op单元测试，Jacoco也提供了可接受的数字。因为它似乎能够准确地确定测试的代码路径。无op测试的覆盖率得分较低或为0%，并且随着测试的完成，得分会增加

更新

---

向落选的选民致辞。也许解决这个问题的一个更合适的工具是。可以在IDE或生成系统中使用。通过适当的配置和规则开发，可以使用它来查找这些不完整的单元测试。我过去曾使用它来查找缺少某些安全相关注释的方法。

您有多种选择：

• 您可能可以使用一些代码分析工具（如checkstyle）来验证每个测试是否都有一个断言。或者使用JUnit规则来验证这一点，但两者都很容易被欺骗，并且只能在表面上起作用

• Jester所做的突变测试同样是一个可行的技术解决方案，而且@Tom_G似乎有一个可行的工具。但根据我的经验，这些工具的速度非常慢，因为它们通过反复更改代码、运行测试、分析结果来完成工作。因此，即使是很小的代码库也需要很多时间，我甚至不会考虑在实际项目中使用它

• 代码评审：这样糟糕的测试很容易被代码评审抓住，而且它们应该是每个开发过程的一部分

所有这些仍然只是表面现象。您应该思考的一个大问题是：为什么开发人员只想创建代码来启动应用程序的某个部分？为什么他们不为他们想要实现的东西编写测试，所以几乎不需要启动应用程序的某些部分。获得一些自动化单元测试的培训，尤其是TDD/BDD，即您首先编写测试的过程

---

根据我的经验，你很可能会听到这样的话：我们不能测试它，因为。。。。您需要找到开发人员不能或不想编写这些测试的真正原因，这可能是他们陈述的原因，也可能不是。然后纠正这些原因，那些讨厌的测试就会自行消失。

你所寻找的确实是突变测试

关于工具支持，您可能还想看看 突变框架（），这是非常有效和可配置的。专业 使用一个编译器集成的变数，让您可以很好地控制 什么应该变异和测试。据我所知，少校还没有 生产gra