你如何测试junit测试

Question

我们如何测试编写的junit测试用例？ 我认为手动测试即创建测试数据并声明期望值和实际值都可以。 但是最近我遇到了一种情况，即junit测试通过了，但是特定的SUT代码在UI测试期间失败了（这意味着junit测试无法保护该错误）。

Answer 1

如果您的测试通过了，但是测试本应涵盖的实际代码 失败了 ，那么将发生以下两种情况之一：

• 测试套件无法适应该特定用例，或者
• 为覆盖特定用例而编写的测试是不够的。

无论如何，您都需要重写测试 。 拥有不允许您防范特定异常行为的测试套件，会使整个测试套件变得一文不值。

您还提到了它在UI测试期间明显失败。 这可能是因为UI和后端测试之间的期望断开。 在这种情况下，要么使后端测试与UI的实际输入对齐，要么寻求实现涵盖UI的工作流的集成测试。

Answer 2

我们如何测试编写的junit测试用例？

你不应该。
单元测试并非万无一失，但测试毫无意义。

您应该将自动测试视为可执行的规范。
通常，如果您的规格不正确，则会陷入困境。 对于自动测试，这是完全相同的事情。

为了避免这种问题或至少减轻它，我赞成：

• 与开发团队的同僚一起审查代码和测试代码。

• 通过集成完成单元测试，并通过业务团队验证的业务测试。

• 不断改进自动测试。

  这很简单：如果在UI手动测试中检测到漏洞，则应立即更新自动测试（如果存在测试但缺少某些检查），否则应创建新测试。

Answer 3

为了亲自验证单元测试的质量，我使用以下技术：

1. 覆盖率指标。 拥有良好的行和分支覆盖范围是个好主意。 但是通常不可能有100％的行覆盖率，并且覆盖率本身并不能保证实际上已经测试过代码，而不能保证简单地从测试类中调用代码。

2. 测试代码审查。 我个人更喜欢编写结构清晰的“设置-运行-断言”测试。 如果缺少“运行”或“确定”步骤，则测试存在问题。

3. 变异测试 。 有一些框架可以让您以某种简单的方式修改生产代码（ 在代码上应用mutators ），然后对修改后的代码运行单元测试，如果没有测试失败，则说明该代码未经过测试或测试很糟糕。 对于Java，我使用PIT变异测试 。

另外，有时不仅要应用单元测试，还应应用其他一些测试技术，例如手动测试，集成测试，负载测试等。

Answer 4

我遇到了junit测试通过但特定的SUT代码失败的情况。

您的单元测试不应错过任何方法的功能或其副作用。 这就是诸如Cobertura之类的代码覆盖工具发挥作用的地方，并不是测试通过了，但是我们需要确保正确地对每个方法及其副作用进行了单元测试/覆盖。

不，代码覆盖率在这里与安慰剂一样糟糕。 您可以拥有100％的线路覆盖率，但仍然处于OP所在的位置？

像Cobertura这样的工具至少可以找到我们正在执行的代码覆盖率的百分比，但是，如果您不关心测试覆盖率，您将得到更多的错误。

要点是，这些覆盖率工具不会告诉您您的内部业务需求是否真正得到满足。