Comment l'unité de test avec ILogger dans ASP.NET de Base

Juste mock ainsi que de toute autre dépendance:

var mock = new Mock<ILogger<BlogController>>();
ILogger<BlogController> logger = mock.Object;

//or use this short equivalent 
logger = Mock.Of<ILogger<BlogController>>()

var controller = new BlogController(logger);

Vous aurez probablement besoin d'installer Microsoft.Extensions.Logging.Abstractions paquet utiliser ILogger<T>.

En outre, vous pouvez créer un véritable enregistreur:

var serviceProvider = new ServiceCollection()
    .AddLogging()
    .BuildServiceProvider();

var factory = serviceProvider.GetService<ILoggerFactory>();

var logger = factory.CreateLogger<BlogController>();

Utiliser un enregistreur de frappe qui utilise ITestOutputHelper (à partir de xunit) à la sortie de capture et de journaux. Voici un petit échantillon qui écrit seulement les state à la sortie.

public class XunitLogger<T> : ILogger<T>, IDisposable
{
    private ITestOutputHelper _output;

    public XunitLogger(ITestOutputHelper output)
    {
        _output = output;
    }
    public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter)
    {
        _output.WriteLine(state.ToString());
    }

    public bool IsEnabled(LogLevel logLevel)
    {
        return true;
    }

    public IDisposable BeginScope<TState>(TState state)
    {
        return this;
    }

    public void Dispose()
    {
    }
}

L'utiliser dans votre unittests comme

public class BlogControllerTest
{
  private XunitLogger<BlogController> _logger;

  public BlogControllerTest(ITestOutputHelper output){
    _logger = new XunitLogger<BlogController>(output);
  }

  [Fact]
  public void Index_ReturnAViewResult_WithAListOfBlog()
  {
    var mockRepo = new Mock<IDAO<Blog>>();
    mockRepo.Setup(repo => repo.GetMany(null)).Returns(GetListBlog());
    var controller = new BlogController(_logger,mockRepo.Object);
    //rest
  }
}

Ajouter mes 2 cents, C'est une aide de la méthode d'extension généralement mis en statique de la classe helper:

static class MockHelper
{
    public static ISetup<ILogger<T>> MockLog<T>(this Mock<ILogger<T>> logger, LogLevel level)
    {
        return logger.Setup(x => x.Log(level, It.IsAny<EventId>(), It.IsAny<object>(), It.IsAny<Exception>(), It.IsAny<Func<object, Exception, string>>()));
    }

    private static Expression<Action<ILogger<T>>> Verify<T>(LogLevel level)
    {
        return x => x.Log(level, 0, It.IsAny<object>(), It.IsAny<Exception>(), It.IsAny<Func<object, Exception, string>>());
    }

    public static void Verify<T>(this Mock<ILogger<T>> mock, LogLevel level, Times times)
    {
        mock.Verify(Verify<T>(level), times);
    }
}

Alors, vous l'utilisez comme ceci:

//Arrange
var logger = new Mock<ILogger<YourClass>>();
logger.MockLog(LogLevel.Warning)

//Act

//Assert
logger.Verify(LogLevel.Warning, Times.Once());

Et bien sûr, vous pouvez facilement étendre, à se moquer de toute attente (c'est à dire attente, message, etc ...)

Il est facile que les autres réponses suggèrent de passer maquette ILogger, mais il devient d'un coup beaucoup plus problématique pour vérifier que les appels ont été effectivement faite à l'exploitant forestier. La raison en est que la plupart des appels ne lui appartiennent pas en propre à la ILogger interface elle-même.

De sorte que la plupart des appels sont des méthodes d'extension qui appel la seule Log méthode de l'interface. La raison pour laquelle il me semble, c'est que c'est beaucoup plus facile de faire de la mise en œuvre de l'interface si vous avez un seul et pas beaucoup de surcharges qui se résume à la même méthode.

L'inconvénient, c'est qu'il est tout à coup beaucoup plus difficile de vérifier qu'un appel a été fait depuis l'appel, vous devez vérifier est très différent de l'appel que vous faites. Il existe différentes approches pour contourner ce problème, et j'ai trouvé que la coutume des méthodes d'extension pour se moquant cadre de la rendre plus facile à écrire.

Voici un exemple d'une méthode que j'ai fait de travailler avec NSubstitute:

public static class LoggerTestingExtensions
{
    public static void LogError(this ILogger logger, string message)
    {
        logger.Log(
            LogLevel.Error,
            0,
            Arg.Is<FormattedLogValues>(v => v.ToString() == message),
            Arg.Any<Exception>(),
            Arg.Any<Func<object, Exception, string>>());
    }

}

Et c'est comment il peut être utilisé:

_logger.Received(1).LogError("Something bad happened");   

Il est exactement comme si vous avez utilisé la méthode directe, le truc c'est que notre méthode d'extension bénéficie d'une priorité parce que c'est "plus proche" dans les espaces de noms que l'original, de sorte qu'il sera utilisé à la place.

Il ne donne malheureusement à 100% de ce que nous voulons, à savoir les messages d'erreur ne sera pas aussi bon, étant donné que nous ne contrôle pas directement sur une chaîne, mais plutôt sur une lambda qui implique la chaîne, mais 95% est mieux que rien 🙂 en Outre, cette démarche permettra de faire le code de test

P. S. Pour Moq on peut utiliser l'approche de l'écriture d'une méthode d'extension pour le Mock<ILogger<T>> qui ne Verify pour obtenir des résultats similaires.