c# - Cómo probar el Ilogger incorporado en el núcleo asp.net

unit-testing logging

Question

Quiero verificar algunos registros registrados. Estoy utilizando el núcleo incorporado asp.net ILogger, e inyectándolo con el núcleo integrado asp.net DI:

private readonly ILogger<InvoiceApi> _logger;

public InvoiceApi(ILogger<InvoiceApi> logger)
{
    _logger = logger;
}

luego lo uso como: _logger.LogError("error));

Traté de burlarme (con moq) como de costumbre:

MockLogger = new Mock<ILogger<InvoiceApi>>();

e inyectar esto en el servicio para la prueba por:

new InvoiceApi(MockLogger.Object);

luego intenté verificar:

MockLogger.Verify(m => m.LogError(It.Is<string>(s => s.Contains("CreateInvoiceFailed"))));

pero tira:

Verificación no válida en un miembro no virtual (anulable en VB): m => m.LogError

Entonces, ¿cómo puedo verificar estos registros registrados?

Answer 1

LogError es un método de extensión (estático), no un método de instancia. No se puede "burlar" directamente los métodos estáticos (por lo tanto, el método de extensión) con un marco de burla, por lo que Moq no puede simular y, por lo tanto, verificar ese método. He visto sugerencias en línea sobre la adaptación / envoltura de la interfaz de destino y hacer sus burlas sobre eso, pero eso significaría reescribir si ha utilizado el ILogger predeterminado en todo el código en muchos lugares. Tendría que crear 2 nuevos tipos, uno para la clase contenedora y el otro para la interfaz simulable.

Answer 2

Como ya dijo @ Nkosi''ve, no puedes burlarte de un método de extensión. Lo que debería burlarse, es el método ILogger.Log , al cual llama LogError . Hace que el código de verificación sea un poco torpe, pero debería funcionar:

MockLogger.Verify(
    m => m.Log(
        LogLevel.Error,
        It.IsAny<EventId>(),
        It.Is<FormattedLogValues>(v => v.ToString().Contains("CreateInvoiceFailed")),
        It.IsAny<Exception>(),
        It.IsAny<Func<object, Exception, string>>()
    )
);

(No estoy seguro de si esto compila, pero entiendes la esencia)

Answer 3

He escrito un breve artículo que muestra una variedad de enfoques, que incluyen la burla del método subyacente Log () como se describe en otras respuestas aquí. El artículo incluye un repositorio completo de GitHub con cada una de las diferentes opciones . Al final, mi recomendación es usar su propio adaptador en lugar de trabajar directamente con el tipo de ILogger, si necesita poder probar que se está llamando.

https://ardalis.com/testing-logging-in-aspnet-core