Header Ads Widget

Ticker

6/recent/ticker-posts

Prueba de la salida de registro en Java

Una de mis publicaciones más populares en este sitio es sobre cómo usar Mockito para simular el registro .

Probar que la salida registrada es la esperada parece estar en la cúspide de una buena o mala idea. ¿El resultado registrado es el comportamiento previsto de la aplicación? ¿O es un detalle de implementación que simplemente está reflejando en una prueba?

Podría decirse que a veces es lo primero ... la tala es el tipo de cosa que importa cuando importa.

Yo diría que a menudo es un nivel demasiado bajo para probarlo, pero es fundamental probarlo cuando:

  • Estás escribiendo un marco de registro que centraliza la lógica de registro
  • Tiene un caso excepcional que DEBE registrarse de manera diferente y necesita bloquear el comportamiento
  • El registro ES la lógica por alguna razón

Tenga en cuenta que me gusta pensar que las pruebas bloquean la lógica: hoy escribimos el código de esta manera, con suerte usando TDD, para lograr algo observable mediante una prueba. La prueba evita que ese comportamiento observable desaparezca al ponerse rojo si alguien lo rompe. Entonces, la prueba bloquea algunas especificaciones.

Iniciar sesión en el mundo moderno

Si desea simular Log4j2 , hágalo . Recientemente me encontré con algo más fácil.

En estos días, nos registramos deliberadamente en la consola del sistema, en lugar de archivos de registro. Esto funciona bien cuando colocamos en contenedores nuestra aplicación o escribimos una AWS Lambda, y queremos que el raspador de registros del entorno de alojamiento extraiga los registros en stdoutlugar de extraer los archivos de registro a medida que los escribimos.

Enviar mensajes de registro a la consola, aunque alguna vez se pensó como un no-no, es esencialmente mucho más limpio que decirle a un agente de registro que vaya y lea un archivo mientras lo escribimos.

¿No podemos simplemente mirar System.outentonces?

Bueno, de hecho podemos. No es necesario registrar un oyente en el marco de registro. Veamos lo que aparece en la consola. Podemos configurar nuestro registrador para escribir en la consola; de hecho, ¡probablemente ya lo haga!

Ingrese los stubs del sistema

Escribiré más sobre esto a su debido tiempo, pero System Stubs es una biblioteca de prueba en la que he trabajado duro en las últimas semanas. Comenzó como un proyecto diferente que bifurqué, y luego esencialmente lo modifiqué para que encajara con el tipo de pruebas que he estado escribiendo. Como tal, está disponible como una extensión JUnit 5 (así como en otras formas).

Imaginemos que tenemos un código bajo prueba que va a realizar un registro, y queremos ver si aparece un mensaje determinado.

He aquí una prueba:

01
02
03
04
05
06
07
08
09
10
11
12
13
@ExtendWith(SystemStubsExtension.class)<font></font>
class TheOneAboutTheLoggingTest {<font></font>
    @SystemStub<font></font>
    private SystemOut systemOut;<font></font>
<font></font>
    @Test<font></font>
    void youKnow_ForLogging() {<font></font>
         doTheThingThatShouldLog();<font></font>
<font></font>
         assertThat(systemOut.getLines())<font></font>
             .anyMatch(line -> line.contains("ERROR This is bad!"));<font></font>
    }<font></font>
}

Analicemos algunos de los elementos de arriba.

Está la extensión JUnit 5 - SystemStubsExtensionNo es gran cosa. Luego hay un SystemOutobjeto, que se usa para capturar System.outmientras el objeto está activo . El objeto es creado por la extensión y se activa justo antes de la prueba y luego se borra.

Mientras se ejecuta la prueba, System.outno aparece en la consola, se almacena en la memoria del SystemOutobjeto TapStream.

En cualquier momento podemos esperar las líneas de texto que han aparecido System.outLa getLinesfunción proporciona una Stream<String>que inspeccionamos aquí usando AssertJ.

Dado que la salida del registro generalmente contiene marcas de tiempo, este método requiere que hagamos algún tipo de verificación de subcadenas para evitar tener que predecir la marca de tiempo. Quizás una biblioteca futura podría ayudar a analizar un poco más la salida.

También vale la pena señalar que NO ver la salida del registro en la consola es un poco molesto durante este tipo de prueba. A su debido tiempo, planeo lanzar la versión 1.2.0, la SystemStubscual permitirá un multiplex donde la salida aparece en la consola Y también se toca. Consulte este archivo README propuesto para obtener más información .

Entonces, ¿está aprovechando System.outel futuro de las pruebas de registros?

Si y no.

Es muy conveniente y fácil de hacer. Entonces, me inclino a hacerlo por defecto.

Sin embargo, para pruebas detalladas de exactamente lo que se envía a la biblioteca de registro, la lectura de cadenas de una consola es un poco complicada.

Publicar un comentario

0 Comentarios