Какое фактическое использование "fail" в тестовом случае JUnit?

Какое фактическое использование "fail" в тестовом случае JUnit?

ОТВЕТЫ

Ответ 1

Некоторые случаи, когда я нашел это полезным:

  • отметьте тест, который является неполным, поэтому он терпит неудачу и предупреждает вас, пока вы не закончите его.
  • убедитесь, что выбрано исключение:
try{
  // do stuff...
  fail("Exception not thrown");
}catch(Exception e){
  assertTrue(e.hasSomeFlag());
}

Примечание:

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

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

Ответ 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)
}

Ответ 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
    }
}

Ответ 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
}

Ответ 5

просто используйте:

org.junit.Assert.fail("Exception expected");

Ответ 6

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

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

  • Передано: проверенная функция успешно выполнена и возвращена данные как ожидаемые
  • Не пройден: функция под тестированием выполнена успешно, но возвращенные данные не ожидались
  • Сбой: функция не выполнялась успешно, и это не было

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

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

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

например.: public Integer add (integer a, Integer b) {return new Integer (a.intValue() + b.intValue())}

  • Пройденный случай: a = новый Interger (1), b = новый Integer (2) и возвращаемая функция 3
  • Не пройденный случай: a = новый Interger (1), b = новый Integer (2), а функция возвратила значение soem, отличное от 3
  • Ошибка: a = null, b = null, и функция выдает исключение NullPointerException

Ответ 7

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

Ответ 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);
}

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