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