Игнорирование stacktrace при тестировании исключений в Junit

Question

Мы тестируем исключения в наших модульных тестах

@Test(expected=IOException.class)
     public void test() {
     // run some code that throws IOException.
}

Тест проходит, но как часть сборки maven, которая выполняет тест, трассировка стека поступает в вывод консоли. Есть ли в любом случае эту трассировку стека можно игнорировать в тестах.

Answer 1

<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.7.1</version>
    <configuration>
        <redirectTestOutputToFile>true</redirectTestOutputToFile>
    </configuration>
</plugin>

Поместите приведенный выше код в раздел плагинов вашего pom.xml.redirectTestOutputToFile удалит трассировку стека с выхода консоли.Очевидно, замените версию серфинга на версию, которую вы используете.

Кстати, параметр redirectTestOutputToFile также доступен в отказоустойчивом плагине , так что вы можете применить его к своим интеграционным тестам таким же образом.

Answer 2

Нет хорошего способа сделать это, и оно того не стоит.Я предполагаю, что напечатанная трассировка стека происходит из вызываемого кода, а не из вашего тестового кода:

public class ExpectedExceptionTest {
  @Test(expected = IOException.class)
  public void test() throws Exception {
    foobar();
  }

  public void foobar() throws IOException {
    try {
      throw new IOException();
    } catch (IOException e) {
      e.printStackTrace(System.err);
      throw e;
    }
  }
}

Здесь, трассировка стека, которая появляется в журнале сборки maven, происходит из обработки ошибок метода, которыйты пытаешься проверить.Вы не хотите изменять эту обработку ошибок.Если тест не пройден, вы хотите знать, что произошло.

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

Итак, можем ли мы установить для System.err значение null, как было предложено в другом месте?Нет. Если вы позвоните

System.setErr(null);

, то это приведет к NullPointerException (с обработкой ошибок, описанной выше).

Если вы используете log4j или подобное для ведения журнала, то вы можетеиметь @Rule, который временно устанавливает уровень ведения журнала на INFO, чтобы исключение не отображалось в ваших журналах.Опять же, отладка не появится, когда она вам больше всего понадобится, если тест не пройден.

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

Answer 3

System.err - это то, на что он печатается, и это PrintStream, который можно изменить во время выполнения.Поэтому в System.err поместите новый PrintStream, созданный из OutputStream, который ничего не печатает при вызове write(int i):

System.setErr(new PrintStream(new OutputStream(){public void write(int i){}}));

Не забудьте создать резервную копию текущего PrintStream в System.хотя после того, как вы закончите, подавите вывод, иначе вы не получите других ошибок, о которых действительно полезно знать.

Вы можете сделать резервную копию и установить подделку в BeforeClass и восстановить в AfterClass или что-то в этом роде.

---

Дополнительные примечания:

Вот более полный набор строк, которые выможете поставить в свой тест:

java.io.PrintStream realErrorStream = System.err;
System.setErr(new java.io.PrintStream(new java.io.OutputStream(){public void write(int i){}}));
...
System.setErr(realErrorStream);

Answer 4

у решение, чтобы утверждать, что я на самом деле ловлю ожидаемое исключение, не видя трассировку стека

@Test
public void test() {
    try {
 // run some code that throws IOException.
    } catch (Exception ex) {
        assertTrue(ex.getClass().equals(IOException.class));
    }
}

Answer 5

В моем случае я делаю assertNotNull с исключением Thrown в блоке catch. Таким образом, если в коде произойдет обратное, я получу assertNotNull Failure. И да Нечего ненавидеть, если напечатана трассировка стека. У него есть причина.

//Building the precondition for test case goes here.
try {
    begin();       
    System.out.println("Expected ConstraintViolationException occurred");
    dao.save(myObject);            
    commit();
} catch (Exception e){
    assertNotNull(e);
} finally {
    rollback();
}

Answer 6

Одна из вещей, которую вы можете сделать, это не использовать функцию ожидаемого исключения.Иногда я делаю это, когда слишком много тестов, и я не хочу, чтобы реальное исключение игнорировалось, потому что сборка maven вывела ожидаемые ожидания.

boolean exceptionOccured = false;
try {
    // My test here);
} catch (ExpectedException ex) {
   exceptionOccured = true;
}
if(!exceptionOccured) {
    Asser.fail();
}