Каково реальное использование 'fail' в тестовом примере JUnit?

Question

Как на самом деле используется 'fail' в тестовом примере JUnit?

Answer 1

В некоторых случаях я нашел это полезным:

• пометьте тест, который является неполным, поэтому он не проходит и предупреждает вас, пока вы не можете его завершить
• убедившись, что выдается исключение:

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

Примечание:

Начиная с JUnit4, есть более элегантный способ проверить, что генерируется исключение: Используйте аннотацию @Test(expected=IndexOutOfBoundsException.class)

Однако, это не сработает, если вы также хотите проверить исключение, тогда вам все еще нужно fail().

Answer 2

Допустим, вы пишете тестовый пример для потока -ve, где тестируемый код должен вызывать исключение

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

Answer 3

Я думаю, что обычный вариант использования - это вызов, когда в отрицательном тесте не было исключений.

Что-то вроде следующего псевдокода:

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
    }
}

Answer 4

Я использовал его в случае, если что-то пошло не так в моем методе @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
}

Answer 5

Так я использую метод Fail.

Существует три состояния, в которых ваш контрольный пример может закончиться в

1. Пройдено: Тестируемая функция успешно выполнена и вернула данныекак и ожидалось
2. Не пройдено: тестируемая функция выполнена успешно, но возвращенные данные не соответствовали ожидаемым
3. Ошибка: функция не была выполнена успешно, и это не было

предназначен (в отличие от отрицательных тестовых случаев, которые ожидают возникновения исключения).

Если вы используете затмение, то три состояния обозначены зеленым, синим и красным маркером соответственно.

Я используюоперация сбоя для третьего сценария.

например: public Integer add (integer a, Integer b) {вернуть новое Integer (a.intValue () + b.intValue ())}

1. Пропущенный регистр: a = новый Interger (1), b = новое целое число (2) и возвращенная функция 3
2. Not Passed Case: a = новый интергер (1), b = новое целое число (2) и функция вернула соему значение otherчем 3
3. Ошибка: a = ноль, b = ноль и функция выдает исключение NullPointerException

Answer 6

Я, например, использую fail() для обозначения тестов, которые еще не завершены (это происходит);в противном случае они будут показаны как успешные.

Возможно, это связано с тем, что мне неизвестна какая-то неполная функциональность (), которая существует в NUnit.

Answer 7

В одновременных и / или асинхронных настройках вы можете проверить, что определенные методы (например, делегаты, прослушиватели событий, обработчики ответов, вы называете его) не вызваны.Помимо фальшивых фреймворков, вы можете вызвать 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");
}

Answer 8

Наиболее важным вариантом использования, вероятно, является проверка исключений.

Хотя 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);
}

Как отмечено в другом комментарии.Проведение теста до тех пор, пока вы не сможете завершить его реализацию, также звучит разумно.