Repository navigation
Improve output of dotnet test with MTP #49712
Description
When running individual test apps, we have output that show actively running tests. Related logic is around https://github.com/microsoft/testfx/blob/94360dfccacfc549d3a385300dba6ab40ca4736d/src/Platform/Microsoft.Testing.Platform/OutputDevice/Terminal/AnsiTerminalTestProgressFrame.cs#L318
We should have similar experience in dotnet test.
Reacted by Frulfump
Reacted by Amaury Levé
Reacted by Amaury Levé
Activity
dotnet testMicrosoft.Testing.Platform experience #45927nohwnd commentedon Jul 9, 2025
Why this was not done is that we can easily have 12 processes writing the info to the screen (via the orchestrator) at the same time. So we need to balance the usability with performance. And see if it even is useful.
I feel like I've written this in a detail somewhere, but I would see it as more useful to write a test that is slow / hanging, but don't write test that is fast. That way I can at least see useful info, instead of getting all updates.
It would also help in ci, where we want to limit the number of updates written to the screen because they are all preserved.
nohwnd commentedon Jul 9, 2025
described it here and here:
microsoft/testfx#3728
microsoft/testfx#3639
Youssef1313 commentedon Aug 6, 2025
@nohwnd Do you want to close as "not planned" then? Or is there some balance we can find?
nohwnd commentedon Aug 7, 2025
To me the solution is described in the second link, introduce a way to notify the progress bar about stuck tests or other interesting events. Rather than showing every single test.
Evangelink commentedon Aug 28, 2025
I am not sure if I am saying the same thing as you did on your last comment @nohwnd but I believe that a quick win would be to do something similar to what is currently done in microsoft/testfx#4221 where we display tests on the available space and when we have more than what we can display we have the
... and X more.Evangelink commentedon May 28, 2026
A few findings after digging into the SDK side, plus thoughts on the trade-off @nohwnd raised.
What's already in
dotnet testThe whole rendering machinery for "active tests + ... and X more" was actually ported from microsoft/testfx#4221 into the SDK and is sitting unused:
TestNodeResultsState.GetRunningTasks(maxCount)already does the trimming withCliCommandStrings.ActiveTestsRunning_MoreTestsCount("... and X more").AnsiTerminalTestProgressFrame.GenerateLinesToRendercaps at ~70% of terminal height and divides the line budget evenly across active assemblies (linesToDistribute / progressItems.Length), sorting so small projects render first.TerminalTestReporter.TestInProgress(...)exists and is gated on_options.ShowActiveTests.What's missing to actually wire it up in the multi-process
dotnet testflow:TestResultMessages,TestStateshas Passed/Skipped/Failed/Error/Timeout/Cancelled, no "started"/"running").TerminalTestReporter.TestInProgressis never called fromTestApplicationHandler.OnTestResultsReceived.MicrosoftTestingPlatformTestCommandconstructsTerminalTestReporterOptionswithoutShowActiveTests = true, and there's no user-facing flag.On the volume/cost concern
I think we can address it without abandoning the "show running tests" UX, by combining two things:
ShowActiveTests=falsewhen output is redirected /CIenv-var is set, so CI logs aren't preserved with hundreds of progress updates,That keeps the common case ("nothing slow") completely silent, while still answering the "is anything hung?" question that's the whole reason for this UX.
Proposed plan for the SDK side
TestInProgressMessage(s)carryingExecutionId, InstanceId, Uid, DisplayNameIPC/Models+IPC/Serializers+RegisterSerializersTestApplicationHandler.OnInProgressReceived→_output.TestInProgress(targetPath, tfm, arch, executionId, uid, displayName)TestApplicationHandler.cs+ adjustTestInProgresssignature to matchTestCompleted--show-active-testsflag, defaulting to TTY-onlyTestCommandParser.cs,Options.cs,MicrosoftTestingPlatformTestCommand.csTerminalTestReporterTerminalTestReporterctorA couple of small drive-by cleanups while in
AnsiTerminalTestProgressFrame.cs:&& falsein the same-progress-item branch (line ~241) disables the "rewrite only the duration" fast path, which becomes noticeably worse for flicker once active tests are streamed,DarkYellow) on entries past a long-running threshold so "the stuck one" is obvious without scanning timings.Show currently running tests in dotnet test MTP output (#49712) (#54486)
Show currently running tests in dotnet test MTP output (dotnet#49712)