团队领导的一个问题是团队成员（有时甚至包括我自己）经常在没有任何测试功能的情况下创建JUnit测试。
它很容易完成，因为开发人员使用他们的JUnit测试作为线束来启动他们正在编码的应用程序的一部分，然后故意或忘记只是在没有任何断言测试或模拟验证的情况下检查它。
然后后来忘记了测试是不完整的，但它们通过并产生了很好的代码覆盖率。运行应用程序并通过它提供数据将创建来自Cobertura或Jacoco的高代码覆盖率统计数据，但除了能够在不爆炸的情况下运行之外，没有任何测试 - 我甚至看到了大型尝试捕获的解决方案在测试中阻止。
是否有报告工具可以测试测试，因此我不需要经常查看测试代码？
我暂时兴奋地发现Jester通过更改测试中的代码（例如if子句）来测试测试并重新运行它以查看它是否破坏了测试。
然而，这不是你可以设置在CI服务器上运行的东西 - 它需要在命令行上进行设置，无法在不显示GUI的情况下运行，只将结果打印到GUI上也需要很长时间才能运行。
答案 0 :(得分：10)
PIT是标准的Java变异测试程序。从他们的网站：
突变测试在概念上非常简单。
故障（或突变）会自动播种到您的代码中，然后运行您的测试。如果您的测试失败，那么突变就会被杀死，如果您的测试通过，那么突变就会存在。
...
传统的测试覆盖率（即行，语句，分支等）仅测量测试执行的代码。它不会检查您的测试是否确实能够检测执行代码中的错误。因此，它只能识别绝对未经过测试的代码。
问题的最极端的例子是没有断言的测试。幸运的是，这些在大多数代码库中都不常见。更常见的是仅通过其套件进行部分测试的代码。仅部分测试代码的套件仍然可以执行其所有分支（示例）。
由于实际上能够检测每个陈述是否经过有意义的测试，因此突变测试是衡量所有其他类型覆盖范围的黄金标准。
您的测试质量可以通过杀死突变的百分比来衡量。
它具有相应的Maven plugin，使其可以作为CI构建的一部分进行集成。我相信下一个版本也将包括与Maven站点报告的正确集成。
此外，创建者/维护者在StackOverflow上非常活跃，并且很好地回应了标记的问题。
答案 1 :(得分：2)
尽可能在实现功能之前编写每个测试或修复测试应该处理的错误。功能或错误修复的顺序为：
答案 2 :(得分：2)
您有多种选择：
您可能可以使用一些代码分析工具（如checkstyle）来验证每个测试都有一个断言。或者使用JUnit规则来验证这一点，但两者都很容易被欺骗，只能在肤浅的层面上使用。
Jester所做的变异测试再次成为可行的技术解决方案，似乎@Tom_G有一个可行的工具。但是这些工具（根据我的经验）非常慢，因为通过一遍又一遍地改变代码，运行测试，分析结果的工作。因此，即使很小的代码库也需要花费大量时间，我甚至不会考虑在实际项目中使用它。
代码评论：代码评审很容易发现这些糟糕的测试，无论如何它们应该成为每个开发过程的一部分。
所有这些仍然只是表面上的痕迹。你应该思考的一个重要问题是：为什么开发人员想要创建代码只是为了启动应用程序的某个部分？他们为什么不为他们想要实现的内容编写测试，因此几乎不需要启动应用程序的部分。获得一些自动化单元测试，特别是TDD / BDD的培训，即首先编写测试的过程。
根据我的经验，您很可能会听到以下内容：我们无法测试这个因为...... 您需要找到开发人员的真正原因，不能或者不想写这些测试，这可能是也可能不是他们陈述的原因。然后解决这些原因，那些可憎的测试将自行消失。
答案 3 :(得分：0)
您正在寻找的确是突变测试。
关于工具支持，您可能还想查看Major 变异框架（mutation-testing.org），非常有效且可配置。重大的 使用编译器集成的mutator，让你可以很好地控制 什么应该变异和测试。据我所知Major还没有 生成图形报告，而不是数据（csv）文件 以任何你想要的方式处理或可视化。
答案 4 :(得分：-1)
您需要考虑Jacoco等覆盖率工具，gradle plugin提供有关覆盖率的报告。我还使用EclEmma Eclipse插件来获得相同的结果，但在IDE中进行了相当不错的集成。
根据我的经验，即使有无操作单元测试，Jacoco也提供了可接受的数字。因为它似乎能够准确地确定测试的代码路径。随着测试变得更加完整，无操作测试得分低或覆盖率为0％，分数增加。
<强>更新 解决选民的问题。也许更适合解决这个问题的工具是PMD。可以在IDE或构建系统中使用。通过适当的配置和规则开发，可以使用它来查找这些不完整的单元测试。我过去曾使用它来查找过去缺少某些与安全相关的注释的方法。