[Feature]: LoggingProvider for DI style tests

[JohnGalt1717]

Problem Statement

Right now if you're using DI and it's creating ILoggers there is no way to force direct this to Tunit so that we can get live output.

Proposed Solution

It would be nice if there was a formal Tunit Logging Provider that could be registered in IApplicationHost.Logging.AddProvider() so that we could dump all of the log data.

Alternatives Considered

No response

Feature Category

Test Execution / Lifecycle

How important is this feature to you?

Important - significantly impacts my workflow

Additional Context

Right now I can't see a way to create my own Logging Provider from the current logger stuff that is in the TestContext. Maybe I'm wrong?

Contribution

• I'm willing to submit a pull request for this feature

[aomader]

Hej @JohnGalt1717,

this is already possible by using a custom ILoggerProvider implementation like the following

using Microsoft.Extensions.Logging;

public class ApplicationLoggerProvider : ILoggerProvider, ILogger
{
    private readonly List<TUnit.Core.Logging.ILogger> _testLoggers = [];

    public IDisposable AddTestLogger(TUnit.Core.Logging.ILogger logger)
    {
        lock (_testLoggers)
        {
            _testLoggers.Add(logger);
        }

        return new RemoveTestLogger(this, logger);
    }

    public void Dispose() { }

    public ILogger CreateLogger(string categoryName) => this;

    public IDisposable? BeginScope<TState>(TState state)
        where TState : notnull => null;

    public bool IsEnabled(LogLevel logLevel) => true;

    public void Log<TState>(
        LogLevel logLevel,
        EventId eventId,
        TState state,
        Exception? exception,
        Func<TState, Exception?, string> formatter
    )
    {
        List<TUnit.Core.Logging.ILogger> loggers;
        lock (_testLoggers)
        {
            loggers = [.. _testLoggers];
        }

        var level = logLevel switch
        {
            LogLevel.Trace => TUnit.Core.Logging.LogLevel.Trace,
            LogLevel.Debug => TUnit.Core.Logging.LogLevel.Debug,
            LogLevel.Information => TUnit.Core.Logging.LogLevel.Information,
            LogLevel.Warning => TUnit.Core.Logging.LogLevel.Warning,
            LogLevel.Error => TUnit.Core.Logging.LogLevel.Error,
            LogLevel.Critical => TUnit.Core.Logging.LogLevel.Critical,
            LogLevel.None => TUnit.Core.Logging.LogLevel.None,
        };

        foreach (var logger in loggers)
        {
            logger.Log(level, state, exception, formatter);
        }
    }

    private class RemoveTestLogger(ApplicationLoggerProvider provider, TUnit.Core.Logging.ILogger logger) : IDisposable
    {
        public void Dispose()
        {
            lock (provider._testLoggers)
            {
                provider._testLoggers.Remove(logger);
            }
        }
    }
}

configuring it in your host builder like

var applicationLoggingProvider = ... // depends on your setup to get this

builder.ConfigureLogging(l => {
    l.ClearProviders();
    l.AddProvider(applicationLoggingProvider);
});

and then finally configuring your tests to get the logs from the application like

[BeforeEvery(Test)]
public static void InstallLogging(TestContext context)
{
    var applicationLoggingProvider = ... // get that from somewhere again
    var testLogger = context.GetDefaultLogger();

    var uninstaller = applicationLoggingProvider.AddTestLogger(testLogger);
    
    context.StateBag["uninstaller"] = uninstaller;
}

[AfterEvery(Test)]
public static void UninstallLogging(TestContext context)
{
    var uninstaller = (IDisposable)context.StateBag["uninstaller"]!;
    uninstaller.Dispose();
}

Note that this might be very different, depending on how you architecture your resources, but I think you get the gist.

[thomhurst]

Thanks for the example @aomader 😄

Another example can be found here: https://github.com/thomhurst/TUnit/blob/main/TUnit.AspNetCore/Logging/TUnitAspNetLogger.cs

Basically, there's no out of the box solution because it all differs on how your tests are set up.

If you start a server once and share it among all your tests, then associating requests/responses to a specific test context isn't possible without a bit more setup because it'll exist in a different Async context.

You could send the Test ID in a header, and have some middleware/logger registered to find this and lookup the specific test context etc.

There is no one size fits all

[thomhurst]

@JohnGalt1717 See docs here: https://tunit.dev/docs/examples/aspnet/#tunit-logging-integration

[JohnGalt1717]

Thanks!