2011-01-10 15 views
20

Estoy usando slf4j y quiero probar mi código unitario para asegurarme de que los mensajes de advertencia/error se generan bajo ciertas condiciones. Prefiero que estas sean pruebas unitarias estrictas, por lo que preferiría no tener que arrancar la configuración de registro desde un archivo para probar que se generan los mensajes de registro. El marco burlón que estoy usando es Mockito.¿Cuál es la mejor manera de probar unidades los mensajes de registro SLF4J?

+0

Dado que SLF4J es solo una "fachada" para otras implementaciones de registro, no puede probarlo por sí solo, también debe especificar la implementación que está utilizando. – darioo

+1

@darioo - No es cierto. Podría agregar un setter a mi clase para pasar el registrador de la prueba, luego pasar una instancia de Logger burlada y verificar que se hicieron las llamadas de registro apropiadas. Esperaba obtener una solución más elegante que agregar un método de configuración solo para probar y hacer que mi instancia de Logger no sea definitiva. –

+0

Como nota aparte, el libro en general excelente "Software orientado a objetos en crecimiento" tiene un capítulo sobre pruebas unitarias de la explotación forestal. No es del todo convincente, pero está bien pensado, y vale la pena leerlo (http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=sr_1_1 ? ie = UTF8 & s = books & qid = 1294688741 & sr = 8-1) – skaffman

Respuesta

9

Creo que podría resolver su problema con un appender personalizado. Cree un appender de prueba que implemente el org.apache.log4j.Appender, y configure su appender en el log4j.properties y cárguelo cuando ejecute los casos de prueba.

Si llama de nuevo al instrumento de prueba de que appender puede comprobar los mensajes registrados

+3

Se agradecería mucho si puede ofrecer algunas muestras de código. – kenshinji

+0

@kenshinji Aquí se ofrece un ejemplo: https://stackoverflow.com/a/1828268/2521769 –

1

En lugar de burlarse de SLF4J, podría realizar las llamadas de registro importantes que necesita para probar dentro de sus propios métodos que puede simular más fácilmente.

Si realmente quiere burlarse de SLF4J, apostaría a que podría crear su propio proveedor que le permitiera suministrar un registrador de simulación desde el lado SLF4J en lugar de inyectar uno en sus objetos de servicio.

0

similares a @Zsolt, puede burlarse de log4j Appender y la puso en el Logger, a continuación, comprobar las llamadas a Appender.doAppend(). Esto le permite realizar pruebas sin tener que modificar el código real.

10

Para probar slf4j sin depender de una implementación específica (como log4j), puede proporcionar su propia implementación de registro slf4j como se describe en this SLF4J FAQ. Su implementación puede registrar los mensajes que fueron registrados y luego ser interrogados por las pruebas de su unidad para su validación. El paquete slf4j-test hace exactamente esto. Es una implementación de registro slf4j en memoria que proporciona métodos para recuperar mensajes registrados.

5

Una mejor aplicación de la prueba de SLF4J que funciona muy bien en un ambiente con la ejecución de pruebas concurrentes es https://github.com/portingle/slf4jtesting

He intervino en una discusión sobre algunas pruebas de registro slf4j y las limitaciones de los enfoques de prueba existente cuando se trata de a la ejecución de prueba concurrente.

Decidí poner mis palabras en el código y ese git repo es el resultado.

+0

Esperemos que pronto aparezca una tercera respuesta de alguien que tenga una implementación de prueba aún mejor de SLF4j ....;) – Adam

Cuestiones relacionadas