2017-01-04 3 views
2

Как правило, я выбрал как можно больше Exceptions: он отклоняет код (и я рассматриваю проверенный Exceptions как сомнительный аспект Java). Я склонен использовать их при «уточнении» кода, т. Е. Когда это имеет смысл для конкретного контекста.JUnit обработка RuntimeException (в частности)

Такой подход становится немного сложным, когда переопределение методов суперкласса/интерфейса, которые не бросают необходимое Exception, и поэтому я, как правило, сделать это:

@Override 
public void close() { 
    try { 
     _close(); 
    } catch (Exception e) { 
     throw new RuntimeException(e); 
    } 
} 

где _close частный метод, который делает все бизнес ,

Проблема, когда речь идет о JUnit, если вы на самом деле хотите, чтобы испытать что-то, где исключение брошенную _close() является то, что в результате RuntimeException, кажется, обрабатывается JUnit в «безусловной» способом: он, кажется, всегда остановить тест с сообщением об отказе ... даже если вы на самом деле поймаете и справитесь с ним в try .. catch!

Существует своего рода «обходной путь» для этого, который я нашел (класс CUT закрывает все его closeableComponents, когда он закрыт):

@Test (expected = RuntimeException.class) 
public void errorFlagShouldBeSetIfAnyCloseablesThrowExceptionWhenCUTCloses() throws Exception { 
    Closeable spyCloseable = spy(new Closeable(){ 
     @Override 
     public void close() throws IOException { 
      throw new IOException("dummy"); 
     }}); 
    spyCUT.addCloseableComponent(spyCloseable); 
    Exception blob = null; 
    try{ 
     spyCUT.close(); 
    }catch(Exception e){ 
     blob = e; 
    } 
    assertThat(spyCUT.getErrorFlag()).isTrue(); 
    if(blob != null){ 
     throw blob; 
    } 

Т.е. если у вас нет этой настройки expected, вы всегда получаете отказ теста (из-за RuntimeException «игнорирование» try .. catch). Но для того, чтобы удовлетворить expected вам тогда придется повторно бросит RuntimeException в конце теста ...

... есть ли способ варьирования обработки JUnit по RuntimeExceptions?

ответ

1

Что-то должно быть не так в вашей настройке. JUnit делает нет имеет такую ​​специальную обработку для исключений во время выполнения.

Я собрал этот MCVE; и это проходит.

static class CUT { 
    void close(Closeable _close) { 
     try { 
      _close.close(); 
     } catch (Exception e) { 
      throw new RuntimeException(e); 
     } 
    } 
} 

@Test 
public void test() throws Exception { 
    Closeable spyCloseable = Mockito.spy(new Closeable() { 
     @Override 
     public void close() throws IOException { 
      throw new IOException("dummy"); 
     } 
    }); 
    Exception blob = null; 
    try { 
     new CUT().close(spyCloseable); 
     fail("should have thrown"); 
    } catch (Exception e) { 
     blob = e; 
    } 
    assertThat(blob.getMessage(), is("java.io.IOException: dummy")); 
} 

Это не совсем то, что у вас там есть; но «достаточно близко» в моем сознании.

Короче говоря: ваш ответ исходит из какого-то другого места. Я предлагаю: делать то же, что и я: создать true mcve; и прокладывайте себе путь оттуда!

+0

Большое спасибо. Я проверил ваш тест, и он точно так же, как вы говорите. Даже если я просто брошу новое RuntimeException в try .. catch в тесте, это исключение действительно попадает в catch. Все очень озадачительно. Это было сделано как «Run as JUnit Test» в Eclipse. С моим «реальным» проектом я использую градиентные и текущие тесты, используя плагин Eclipse STS Gradle. Я также использую AssertJ, а не Hamcrest ... вам придется «работать по-своему», как вы говорите. –

+0

Спасибо за отзыв/быстро принимаем! Да; Думаю, вам нужно пошаговую тщательную отладку; поскольку я не вижу ничего в этом списке, который вы только что дали, что объяснит, что вы видите. И для записи: я только запускал этот тест в затмении и встроенный «run as Junit» – GhostCat

Смежные вопросы