¿Puedo ejecutar las pruebas JUnit automáticamente una vez con todos los registros activados y una vez con todos los registros deshabilitados?

Question

He encontrado una solución, vea mi propia respuesta a continuación. ¿Alguien tiene uno más elegante?

Quiero hacer esto para aumentar la cobertura del código y encontrar errores sutiles.

asumir la siguiente clase a ensayar:

public class Foo { 
    private final Logger logger = LoggerFactory.getLogger(Foo.class); 
    public void bar() { 
     String param=[..]; 
     if(logger.isInfoEnabled()) logger.info("A message with parameter {}", param); 

     if(logger.isDebugEnabled()) { 
      // some complicated preparation for the debug message 
      logger.debug([the debug message]); 
     } 
    } 
} 

y la siguiente prueba de clase:

public class FooTest { 
    @Test 
    public void bar() { 
     Foo foo=new Foo(); 
     foo.bar(); 
    } 
} 

Una herramienta de código-cobertura como, por ejemplo, Cobertura informará correctamente que solo se han verificado algunas de las ramas condicionales.

la información y la depuración se activan o desactivan para el registrador.

Además de verse mal en su puntaje de cobertura, esto representa un riesgo real.

¿Qué pasa si hay algún efecto secundario causado por el código dentro if (logger.isDebugEnabled())? ¿Qué pasa si su código solo funciona si DEPURACIÓN está habilitada y falla miserablemente si el nivel de registro está establecido en INFO? (En realidad, esto sucedió en uno de nuestros proyectos: p)

Así que mi conclusión es que el código contiene declaraciones registrador debe siempre ser probados una vez con todo el registro habilitado y una vez con todo el registro desactivado ...

Es Hay una manera de hacer algo así con JUnit? Sé cómo habilitar o deshabilitar globalmente todos mis registros en Logback, por lo que el problema es: ¿cómo puedo ejecutar las pruebas dos veces, una con el registro habilitado, una vez con el registro deshabilitado?

p.s. Estoy al tanto de this question pero no creo que sea un duplicado. Me preocupan menos los valores de cobertura absolutos, pero sobre errores sutiles y difíciles de encontrar que podrían estar contenidos dentro de un if (logger.isDebugEnabled()).

Answer 1

He resuelto este problema implementando una clase base que las clases de prueba deberían extenderse si se desea dicha funcionalidad.

El artículo Writing a parameterized JUnit test contenía la solución.

Consulte LoggingTestBase para la clase base de registro y LoggingTestBaseExampleTest para obtener un ejemplo sencillo que lo esté usando.

Cada método de ensayo contenida se ejecuta tres veces:

1. Se ejecuta utilizando el registro como se define en logback-test.xml como de costumbre. Se supone que esto ayuda mientras escribe/depura las pruebas.

2. Se ejecuta con todos los registros habilitados y escritos en un archivo. Este archivo se elimina después de la prueba.

3. Se ejecuta con todos los registros deshabilitados.

Sí, LoggingTestBase necesita documentación;)

Answer 2

Recomendaría cambiar de JUnit a TestNG. TestNG tiene muchas funciones avanzadas sobre JUnit. Le permite ejecutar sus pruebas varias veces con una configuración diferente y creo que eso es lo que necesita

Answer 3

has necesitado simple mantenimiento de dos archivos de configuración de registro separado? Cada uno se registraría en diferentes niveles desde el registrador de raíz.

Todo el registro desactivado:

... 
<root> 
    <priority value="OFF"/> 
    <appender-ref ref="LOCAL_CONSOLE"/> 
</root> 
... 

Todo el registro activado:

... 
<root> 
    <priority value="ALL"/> 
    <appender-ref ref="LOCAL_CONSOLE"/> 
</root> 
... 

ejecución sería especificar diferentes configuraciones en la ruta de clase a través de un parámetro del sistema:

-Dlog4j.configuration=path/to/logging-off.xml 
-Dlog4j.configuration=path/to/logging-on.xml 

Answer 4

eqbridges sugerencia de simplemente ejecutar las pruebas dos veces con diferentes contextos de registro parece el más simple. No tiene que recordar codificar la lógica en cada prueba bendecida, para obtener una gran ventaja. La otra es que se puede ver qué nivel de registro es el culpable con mucha facilidad.

Dicho esto, hay un par de estrategias si solo tiene que hacer esto en una prueba.

Para 3.8 Pondría todo en suites y haré dos suites, una para cada nivel de registro, que establece el nivel de registro antes de ejecutar las pruebas. Esto es funcionalmente lo mismo que ejecutar todo el conjunto de pruebas dos veces con diferentes parámetros de línea de comandos, excepto que lo obtiene con una ejecución.

En JUnit 4.x un par de opciones adicionales vienen a la mente:

Uno de ellos es un corredor personalizado. Aunque no puedo pensar en todo lo que tendrías que hacer para que esto funcione, pero un corredor que realmente ejecuta la prueba dos veces y anota la prueba con @RunWith tu corredor personalizado podría funcionar.

El otro es pruebas parametrizadas. Aunque en realidad tendría que configurar cada prueba para tomar parámetros (esto requiere un constructor que tome los argumentos) y luego establecer el nivel de registro de acuerdo con el parámetro.

EDITAR: En respuesta a su solicitud de instrucciones sobre las pruebas paramterizadas, here es el javadoc en el corredor para comenzar, y here es una guía más práctica.

Answer 5

Si cree que tiene demasiados registros si enciende todo, tal vez podría intentar reducir la cantidad de registros. No es muy útil si es demasiado para que la computadora procuda, no importa que un humano lea.