Jak przetestować wbudowany rdzeń asp.net Ilogger

Question

Chcę zweryfikować niektóre logi zalogowane. Używam rdzeń asp.net wbudowany ILogger i wstrzyknąć go z rdzeniem asp.net wbudowanym DI:

private readonly ILogger<InvoiceApi> _logger; 

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

potem używać go jak: _logger.LogError("error));

Próbowałem go wyśmiewać (z MOQ) jak zwykle:

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

i wstrzykiwać w usłudze do testów:

new InvoiceApi(MockLogger.Object); 

następnie trie d zweryfikować:

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

ale rzucać:

Nieprawidłowy zweryfikować na nie-wirtualnej (VB) w przeciążać użytkownika: m => m.LogError

Tak, jak można Weryfikuję logowane te logi?

Answer 1

Jak już powiedział @ Nkosi've, nie można kpić z metody rozszerzenia. To, co musisz , powinno być fałszywe, to the ILogger.Log method, które LogError calls into. To sprawia, że ​​kod weryfikacyjny nieco niezgrabne, ale to powinno działać:

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>>() 
    ) 
); 

(Nie wiem, czy to kompiluje, ale masz sedno)

Answer 2

LogError jest metodą rozszerzenia (statyczną) a nie metodą instancji. Nie można "bezpośrednio" symulować metod statycznych (stąd metoda rozszerzania) za pomocą szyderczych ram, w związku z czym Moq nie jest w stanie udawać, a zatem weryfikować tej metody. Widziałem sugestie online dotyczące adaptacji/owijania interfejsu docelowego i robienia na tym twoich mocków, ale to oznaczałoby przepisanie, jeśli używałbyś domyślnego ILogger w całym kodzie w wielu miejscach. Będziesz musiał utworzyć 2 nowe typy, jeden dla klasy opakowania, a drugi dla interfejsu z możliwością zarządzania.

Answer 3

Napisałem short article pokazując różne podejścia, włączając w to wyśmiewanie podstawowej metody Log(), jak opisano w innych odpowiedziach tutaj. Artykuł zawiera a full GitHub repo with each of the different options. Ostatecznie zalecam używanie własnego adaptera zamiast pracy bezpośrednio z typem ILogger, jeśli musisz mieć możliwość przetestowania jego wywoływania.

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