Ignorando StackTrace cuando las pruebas de excepciones en Junit

Question

Estamos probando excepciones en nuestra unidad de pruebas

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

La prueba está pasando sino como parte de la construcción experto que se ejecuta la prueba, el StackTrace viene en la consola salida. ¿Hay alguna forma en que este stacktrace se pueda ignorar en las pruebas?

Answer 1

No hay una buena manera de hacer esto, y no vale la pena de todos modos. Asumo que el StackTrace impresa está viniendo del código de llamada, y no de su código de prueba:

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

Aquí, el StackTrace que aparece en el registro de Maven build viene de la gestión de errores del método que usted' Estoy tratando de probar. No desea cambiar este manejo de error. Si la prueba falla, entonces quieres saber qué pasó.

Si lo cambia, también complicará el código bajo prueba innecesariamente. Además de esta prueba específica, siempre quieres que aparezca la pila.

Entonces, ¿podemos establecer que System.err sea nulo, como se sugirió en otra parte? No. Si usted llama

System.setErr(null); 

A continuación, esto se traducirá en una NullPointerException (con el manejo de error anterior).

Si usa log4j o similar para su registro, entonces puede tener un @Rule que establece temporalmente el nivel de registro en INFO para que la excepción no aparezca en sus registros. De nuevo, la depuración no aparecerá cuando más lo necesite, si la prueba falla.

Obtengo estas trazas de pila de excepción todo el tiempo en mi (s) salida (s) de compilación del proyecto. Yo sólo acepto y felicito a mí mismo que estoy probando las condiciones de error correctamente :-)

Answer 2

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

Coloque el código anterior en la sección de plugins de su pom.xml. redirectTestOutputToFile eliminará el stacktrace de la salida de la consola. Obviamente, reemplace la versión de surfire con la versión que está usando.

BTW el parámetro redirectTestOutputToFile está disponible en el failsafe plugin también, por lo que puede aplicar esto a sus pruebas de integración de la misma manera.

Answer 3

y solución de afirmar que en realidad coger excepción esperada sin ver StackTrace es

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

Answer 4

Una de las cosas que se pueden hacer, es no utilizar la función de excepción esperada. A veces hago esto, cuando hay demasiadas pruebas, y no quiero que se ignore una excepción real porque la construcción maven ha impreso expectativas esperadas.

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

Answer 5

System.err es lo que se imprime, y es un PrintStream que se puede modificar en tiempo de ejecución. Así, en el System.err, poner un nuevo PrintStream hecha de un OutputStream que imprime nada cuando write(int i) se llama:

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

Recuerde hacer copias de seguridad del sistema actual en PrintStream.sin embargo, después de haber terminado de suprimir el resultado, de lo contrario no recibirá otros errores que podrían ser útiles para conocer.

Puede hacer una copia de seguridad y configurar el falso en BeforeClass y restaurar en AfterClass o algo así.

---

Notas adicionales:

Aquí hay un conjunto más completo de líneas que puede poner en su ensayo:

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 6

En mi caso, estoy haciendo un assertNotNull con excepción lanzada en el bloque catch . De esta forma, si sucediera lo contrario en el código, obtendré assertNotNull Failure. Y Sí, no hay nada de lo que odiarse si se imprime stacktrace. Tiene una razón.

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