在JUnit测试案例中，“ fail”的实际用法是什么？

在JUnit测试案例中，“ fail”的实际用法是什么？

我发现它有用的某些情况：

• 标记未完成的测试，因此它会失败并警告您，直到您可以完成它
• 确保引发异常：

try{
  // do stuff...
  fail("Exception not thrown");
}catch(Exception e){
  assertTrue(e.hasSomeFlag());
}

注意：

从JUnit4开始，有一种更优雅的方法来测试是否引发了异常：使用批注 @Test(expected=IndexOutOfBoundsException.class)

但是，如果您还想检查异常，则此方法将无效，那么您仍然需要fail()。

可以说您正在编写-ve流的测试用例，其中正在测试的代码应引发异常

try{
   bizMethod(badData);
   fail(); // FAIL when no exception is thrown
} catch (BizException e) {
   assert(e.errorCode == THE_ERROR_CODE_U_R_LOOKING_FOR)
}

我认为通常的用例是在否定测试中没有引发异常时调用它。

类似于以下伪代码：

test_addNilThrowsNullPointerException()
{
    try {
        foo.add(NIL);                      // we expect a NullPointerException here
        fail("No NullPointerException");   // cause the test to fail if we reach this            
     } catch (NullNullPointerException e) {
        // OK got the expected exception
    }
}

我在@Before方法中可能出现问题的情况下使用了它。

public Object obj;

@Before
public void setUp() {
    // Do some set up
    obj = new Object();
}

@Test
public void testObjectManipulation() {
    if(obj == null) {
        fail("obj should not be null");
     }

    // Do some other valuable testing
}

这就是我使用Fail方法的方式。

有三种状态可以使您的测试用例最终进入

1. 通过：被测函数成功执行，并按预期返回数据
2. 未通过：被测函数成功执行，但返回的数据与预期不符
3. 失败：函数未成功执行，因此未成功执行

预期的（不同于期望发生异常的否定测试用例）。

如果使用的是日食，则三个状态分别由绿色，蓝色和红色标记指示。

我将失败操作用于第三种情况。

例如：public Integer add（integer a，Integer b）{return new Integer（a.intValue（）+ b.intValue（））}

1. 通过的情况：a =新的Interger（1），b =新的Integer（2），函数返回3
2. 未通过的情况：a =新的Interger（1），b =新的Integer（2），并且函数返回的soem值不是3
3. 失败的情况：a = null，b = null，并且该函数引发NullPointerException

例如，我fail()用来表示尚未完成的测试（发生）；否则，它们将显示为成功。

这可能是由于我没有意识到NUnit中存在某种不完整（）功能的事实。

在并发和/或异步设置中，您可能想要验证未调用某些方法（例如，委托，事件侦听器，响应处理程序，您为其命名）。除了模拟框架，您可以调用fail()这些方法使测试失败。在这种情况下，超时是另一种自然的失败情况。

例如：

final CountDownLatch latch = new CountDownLatch(1);

service.asyncCall(someParameter, new ResponseHandler<SomeType>() {
    @Override
    public void onSuccess(SomeType result) {
        assertNotNull(result);
        // Further test assertions on the result
        latch.countDown();
    }

    @Override
    public void onError(Exception e) {
        fail(exception.getMessage());
        latch.countDown();
    }
});

if ( !latch.await(5, TimeUnit.SECONDS) ) {
    fail("No response after 5s");
}

最重要的用例可能是异常检查。

尽管junit4包含用于检查是否发生异常的预期元素，但它似乎不是较新的junit5的一部分。使用而fail()不是的另一个优势expected是，您可以将其与finally允许测试用例清除结合使用。

dao.insert(obj);
try {
  dao.insert(obj);
  fail("No DuplicateKeyException thrown.");
} catch (DuplicateKeyException e) {
  assertEquals("Error code doesn't match", 123, e.getErrorCode());
} finally {
  //cleanup
  dao.delete(obj);
}

如另一条评论所述。测试失败直到您可以完成实施也听起来很合理。