我们如何测试我们编写的 junit 测试用例？我认为手动测试，即创建测试数据并断言预期值和实际值都可以。但是最近我遇到了一种情况，即 junit 测试通过但特定的 SUT 代码在 UI 测试期间失败（这意味着 junit 测试未能保护错误）。
【问题讨论】：
如果您的测试通过，但测试要覆盖的实际代码是失败，那么发生了以下两种情况之一：
无论如何，您都需要重写您的测试。拥有一个不允许您防范特定异常行为的测试套件会使您的整个测试套件一文不值。
您还提到它在 UI 测试期间显式失败。这可能是由于 UI 和后端测试之间的期望脱节造成的。在这种情况下，要么将后端测试与 UI 的实际输入对齐，要么寻求实施涵盖 UI 工作流程的集成测试。
【讨论】：
我们如何测试我们编写的 junit 测试用例？
你不应该。
单元测试并非万无一失，但测试测试毫无意义。
您应该将自动测试视为可执行规范。
通常，如果您的规格有误，您就会陷入困境。
对于自动测试，它是完全一样的。
为了避免或至少减少此类问题，我赞成：
与开发团队的同行一起审查代码和测试代码。
通过业务团队验证的集成和业务测试完成单元测试。
不断改进自动测试。
很简单：一旦在 UI 手动测试中检测到漏洞，如果测试存在但缺少某些检查，则应更新自动测试，否则如果缺少测试，则应创建新测试。
【讨论】：
为了亲自验证单元测试的质量，我使用了以下技术：
覆盖率指标。拥有良好的线路和分支覆盖率是个好主意。但是通常不可能有 100% 的行覆盖率，而且覆盖率本身并不能保证代码已经过实际测试，而只是从测试类中调用。
测试代码审查。就个人而言，我更喜欢编写具有清晰结构“设置-运行-断言”的测试。如果缺少“运行”或“断言”步骤，则说明测试有问题。
Mutation testing。有些框架允许您以某种简单的方式修改生产代码（在代码上应用 mutators），然后对修改后的代码运行单元测试，如果没有测试失败，则此代码未经过测试或测试很糟糕。对于 Java，我使用 PIT Mutation Testing。
此外，有时不仅要应用单元测试，还要应用其他一些测试技术——手动测试、集成测试、负载测试等。
【讨论】：
我遇到过 junit 测试通过但 特定 SUT 代码失败。
您的单元测试不应错过任何方法的功能或其副作用的覆盖范围。这就是 Cobertura 这样的代码覆盖工具发挥作用的地方，并不是测试通过了，但我们需要确保每个方法及其副作用都经过单元测试/正确覆盖。
不，代码覆盖率在这里就像安慰剂一样糟糕。你可以拥有 100% 线路覆盖，但仍处于与 OP 相同的修复中？
像 Cobertura 这样的工具至少可以找出我们正在执行的代码覆盖率的百分比，但是，如果您不关心测试覆盖率，您会遇到更多错误。
主要的一点是，这些覆盖工具并不能告诉您是否真正满足了您的内部业务需求。
【讨论】：