Подтвердить что ты не робот

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

System.setErr(null);

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Вы можете выполнить резервное копирование и установить подделку в 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);

Ответ 4

y решение утверждать, что я действительно поймаю ожидаемое исключение, не видя stacktrace

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

Ответ 5

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

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

Ответ 6

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

//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();
}