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