jUnit failed() 约定

Question

我想知道，按照惯例，当测试失败时，是否适合：

• 说出为什么失败（业务逻辑）
• 说出为什么看到消息（应该抛出异常，但没有）

例如，

fail("Accessed the element which does not exist");

或者

fail("ArrayIndexOutOfBoundException was expected but something bad happened");

通常首选哪一个/接受？

Answer 1

首先，如果您希望测试的 API 抛出异常，而不是使用 fail() 执行 try-catch...

@Test
public void testMe() {
   try {
      api.testThis();
      fail("should not reach here");
   }
   catch(MyException e) {}
}

...您应该这样做:-

@Test(expected=MyException.class)
public void testMe() {
   api.testThis();
}

也就是说，我很少使用 fail()。如果我需要执行某些验证并且条件失败，我很可能会使用断言而不是使用 fail()... 例如：-

... 而不是...

@Test
public void testMe() {
   boolean bool = api.testThis();
   if (!bool) {
      fail("should be true because bla bla bla");
   }
}

... 这样做:-

@Test
public void testMe() {
   boolean bool = api.testThis();
   assertTrue("bla bla bla",bool);
}

但是，如果您确实需要使用 fail()，请详细说明它失败的原因，而不是“不应该到达此处”或“应该在此处失败”，因为这对以下人员没有帮助：阅读测试用例。

当然，这些只是简单的例子……但我想我已经明白了我的观点。 :)

Answer 2

鉴于这是测试代码，不应该将其纳入最终版本，我想说越详细越好。因此，我会选择第一个 - 它更清楚问题的根本原因是什么，这使得更容易纠正。

在任何情况下我都会避免使用第二个，因为它对测试人员来说不是很有帮助，并且如果它确实以某种方式进入最终版本，那么对于最终用户来说，它比第一个更加神秘 - 它对测试人员或其他人来说根本没有帮助用户一样。

我考虑的另一种选择是不指示发生了异常，而是提供实际异常的详细信息 - 这就是发明堆栈跟踪的原因。这将比列出的任何一种方法传达更多的细节。

Answer 3

如果有关于此的约定，我会忽略它。您应该说最能向看到此消息的人传达问题本质的任何内容，以便尽可能轻松地解决问题。在这方面，遵守惯例常常会失败。