Registrador Burlón y LoggerFactory con PowerMock y Mockito

Algo tarde para la fiesta - estaba haciendo algo similar y necesitaba algunos consejos y terminé aquí. Sin crédito: tomé todo el código de Brice, pero obtuve "cero interacciones"que Cengiz.

Usando la orientación de lo que jheriks amd Joseph Lust había puesto creo que sé por qué - Tenía mi objeto bajo prueba como un campo y newed en un @Antes a diferencia de Brice. Entonces el logger real no era el simulacro sino una clase real iniciada como jhriks sugirió...

Normalmente lo haría haga esto para mi objeto bajo prueba para obtener un objeto nuevo para cada prueba. Cuando moví el campo a un local y lo newed en la prueba funcionó bien. Sin embargo, si probé una segunda prueba, no fue el simulacro en mi prueba, sino el simulacro de la primera prueba y volví a tener cero interacciones.

Cuando pongo la creación del mock en la @BeforeClass el logger en el objeto bajo prueba es siempre el mock pero vea la nota a continuación para los problemas con esto...

Clase bajo prueba

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyClassWithSomeLogging  {

    private static final Logger LOG = LoggerFactory.getLogger(MyClassWithSomeLogging.class);

    public void doStuff(boolean b) {
        if(b) {
            LOG.info("true");
        } else {
            LOG.info("false");
        }

    }
}

Prueba

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import static org.mockito.Mockito.*;
import static org.powermock.api.mockito.PowerMockito.mock;
import static org.powermock.api.mockito.PowerMockito.*;
import static org.powermock.api.mockito.PowerMockito.when;


@RunWith(PowerMockRunner.class)
@PrepareForTest({LoggerFactory.class})
public class MyClassWithSomeLoggingTest {

    private static Logger mockLOG;

    @BeforeClass
    public static void setup() {
        mockStatic(LoggerFactory.class);
        mockLOG = mock(Logger.class);
        when(LoggerFactory.getLogger(any(Class.class))).thenReturn(mockLOG);
    }

    @Test
    public void testIt() {
        MyClassWithSomeLogging myClassWithSomeLogging = new MyClassWithSomeLogging();
        myClassWithSomeLogging.doStuff(true);

        verify(mockLOG, times(1)).info("true");
    }

    @Test
    public void testIt2() {
        MyClassWithSomeLogging myClassWithSomeLogging = new MyClassWithSomeLogging();
        myClassWithSomeLogging.doStuff(false);

        verify(mockLOG, times(1)).info("false");
    }

    @AfterClass
    public static void verifyStatic() {
        verify(mockLOG, times(1)).info("true");
        verify(mockLOG, times(1)).info("false");
        verify(mockLOG, times(2)).info(anyString());
    }
}

Nota

Si tienes dos pruebas con la misma expectativa tuve que hacer la verificación en la @AfterClass ya que las invocaciones en la estática se apilan - verify(mockLOG, times(2)).info("true"); - en lugar de veces(1) en cada prueba como la segunda prueba fallaría diciendo allí donde 2 invocación de esto. Esto es pantalones bonitos, pero no pude encontrar una manera de despejar las invocaciones. Me gustaría saber si alguien puede pensar de todo esto....

En respuesta a su primera pregunta, debería ser tan simple como reemplazar:

   when(LoggerFactory.getLogger(GoodbyeController.class)).thenReturn(loggerMock);

Con

   when(LoggerFactory.getLogger(any(Class.class))).thenReturn(loggerMock);

Con respecto a su segunda pregunta (y posiblemente el comportamiento desconcertante con la primera), creo que el problema es que logger es estático. Así,

private static Logger logger = LoggerFactory.getLogger(GoodbyeController.class);

Se ejecuta cuando se inicializa la clase , no cuando se instanciael objeto . A veces esto puede ser casi al mismo tiempo, por lo que estarás bien, pero es difícil garantizarlo. Para configurar LoggerFactory.getLogger para devolver tu mock, pero la variable logger ya puede haber sido configurada con un objeto Logger real en el momento en que tus mock sean configurados.

Puede configurar el registrador explícitamente usando algo como ReflectionTestUtils (no se si eso funciona con campos estáticos) o cambiarlo de un campo estático a un campo de instancia. De cualquier manera, no necesita burlarse de LoggerFactory.getLogger porque estarás inyectando directamente la instancia de mock Logger.

Creo que puedes restablecer las invocaciones usando Mockito.reset(mockLog). Deberías llamar a esto antes de cada prueba, así que inside @ Before sería un buen lugar.

Use inyección explícita. Ningún otro enfoque le permitirá, por ejemplo, ejecutar pruebas en paralelo en la misma JVM.

Los patrones que utilizan cualquier cosa classloader ancho como carpeta de registro estático o jugando con el medio ambiente piensa como logback.XML son un fracaso cuando se trata de pruebas.

Considere las pruebas paralelizadas que menciono, o considere el caso en el que desea interceptar el registro del componente A cuya construcción está oculta detrás de la api B. Este último caso es fácil de tratar si está utilizando una dependencia inyectada loggerfactory desde la parte superior, pero no si inyecta Logger ya que no hay costura en este ensamblaje en ILoggerFactory.getLogger.

Y tampoco se trata de pruebas unitarias. A veces queremos que las pruebas de integración emitan registros. Queremos que algunos de los registros de pruebas de integración se supriman selectivamente, por ejemplo, para los errores esperados que de otro modo desordenarían la consola de CI y confundirían. Todo es fácil si inyecta ILoggerFactory desde el parte superior de su línea principal (o cualquier marco di que pueda usar)

So...

O bien inyectar un reportero como se sugiere o adoptar un patrón de inyección de la ILoggerFactory. Mediante la inyección explícita de ILoggerFactory en lugar de Logger, puede admitir muchos patrones de acceso / interceptación y paralelización.