[Bug]: Log outputs when running multiple tests in parallel are either missing or incomplete

[traiannemes]

Description

Running tests in VS 2026 with Test Explorer.
If I run a single test then the output is correct.
But when I run multiple tests at the same time the output for some is either missing or incomplet.

TUnitTest.zip

Expected Behavior

All test to output the full logs.

Actual Behavior

Some are missing or partially missing the output logs

Steps to Reproduce

Single test run

Multiple tests to run

TUnit Version

1.12.15

.NET Version

NET 10

Operating System

Windows

IDE / Test Runner

Visual Studio

Error Output / Stack Trace

Additional Context

No response

IDE-Specific Issue?

• I've confirmed this issue occurs when running via dotnet test or dotnet run, not just in my IDE

[thomhurst]

Give the latest version a try

[traiannemes]

Hi @thomhurst , I upgraded to 1.12.41 and unfortunately, I am seeing the same behavior. In the sample provided GetWeatherForecast_ReturnsOk runs first since there is [NotInParallel] at the class level. And the end of the output is cut, vs when running in isolation.

[thomhurst]

Try 1.12.43 please

[traiannemes]

Hi @thomhurst , confirm this is working now with both old fashion way WebApplicationFactory and new one TestWebApplicationFactory Thank you for help!

But, there is a but for our real projects. Unfortunately, our API is pretty heavy, and we could not spin new clients per tests. It would just time out on Azure CI/CD to run all. So we share a single client (and I know this is not right). So, in that situation the behavior is still the same.

Here is the sample project to illustrate that.

TUnitTest.zip

Basically, it looks like this

public class InMemoryPostgres : IAsyncInitializer, IAsyncDisposable
{
    public PostgreSqlContainer Container { get; } = new PostgreSqlBuilder("postgres:16-alpine").Build();
    public async Task InitializeAsync() => await Container.StartAsync();
    public async ValueTask DisposeAsync() => await Container.DisposeAsync();
}

public abstract class ApiTests
{
    [ClassDataSource<TestsBase>(Shared = SharedType.PerTestSession)]
    public required TestsBase TestsBase { get; init; }

    protected HttpClient Client => TestsBase.Client;
}

public class TestsBase : WebApplicationFactory<Program>
{
    [ClassDataSource<InMemoryPostgres>(Shared = SharedType.PerTestSession)]
    public InMemoryPostgres Postgres { get; init; } = null!;

    public HttpClient Client => CreateClient();
}

[NotInParallel]
public class WeatherTests : ApiTests
{
    [Test]
    public async Task GetWeatherForecast_ReturnsOk()
    {
        var response = await Client.GetAsync("/weatherforecast");

        await Assert.That(response.StatusCode).IsEqualTo(HttpStatusCode.OK);
    }

    [Test]
    public async Task PostWeatherForecast_ReturnsOk()
    {

        var response = await Client.PostAsync("/weatherforecast", null);

        await Assert.That(response.StatusCode).IsEqualTo(HttpStatusCode.OK);
    }
}
 

Do you think there is a way to have a fix for basically a share client that runs the test? Thank you in advance.

[traiannemes]

Just a bit more context on our real projects. We have around 500 tests that shared a single client and it takes about 12min to run on Azure CI/CD pipeline. That VM is low on resources. As a comparison it takes about 5min to run all on local machines.
Without a shared client it goes over one hour time limit from Azure and about 20min on local machines.

[thomhurst]

I reckon this could be possible with creating a custom ILogger and doing a bit of setup.

I'm thinking something like:

Tests add a header to their requests like "TestContextId" with that value of TestContext.Current.Id.

Then create a TUnitLogger that implements the Microsoft ILogger and register it in your WebApplicationFactory test overrides.

Then in the logic for that logger, have it accept something like IHttpContextAccessor so it can read the headers for the request, pull out the TestContextId header, then call TestContext.Get(id).GetDefaultLogger().Log(...). This should then route through to the correct test's output.