Surface and re-print handshake failures in dotnet test

[Evangelink]

Follow-up to #54437 addressing the review feedback from @Youssef1313 and the remaining concerns from #51608:

• Are we burying the reason why test host controller failed?
• The error should probably surface in a better way.
• The error should be re-printed towards the end so the user doesn''t have to scroll up to find it.

Changes

• Reword the misleading "race" comment in AssemblyRunCompleted. Controller-only handshakes are already routed to HandshakeFailure by TestApplicationHandler.OnTestProcessExited, so the defensive branch is unreachable in normal operation. The new comment reflects that — it stays as belt-and-suspenders for stray completions after _assemblies.Clear() or future regressions.
• Track each handshake failure (assembly path, target framework, exit code, stdout, stderr) in a List<T> guarded by a lock so we can re-print details at end of run.
• Fix summary-line precedence: anyAssemblyFailed now takes precedence over allTestsWereSkipped. Previously a pure handshake-failure run (zero tests registered) printed "Zero tests ran" as the headline, masking the failure; it now correctly prints "Failed!".
• Append a "Handshake failures:" recap after the summary listing each failing assembly with its exit code and captured stdout/stderr, so users don''t have to scroll to find the actionable cause.
• Tests: extracted CapturingConsole into a shared helper and added coverage for the recap, multiple-failure ordering, the no-failure path, and the existing defensive AssemblyRunCompleted branch.

Localization

The new HandshakeFailuresHeader resource string was added to CliCommandStrings.resx with a descriptive <comment>. The 13 xlf files were regenerated via /t:UpdateXlf /p:UpdateXlfOnBuild=true (do not hand-edit — entries are in state="new" for translators per the repo workflow).

Verification

.\.dotnet\dotnet exec artifacts\bin\redist\Debug\dotnet.Tests.dll -method "*HandshakeFailure*" -method "*AssemblyRunCompleted_WhenExecutionIdUnknown*"
=== TEST EXECUTION SUMMARY ===
   dotnet.Tests  Total: 5, Errors: 0, Failed: 0, Skipped: 0, Not Run: 0, Time: 0.323s

cc @Youssef1313

[Copilot]

Pull request overview

Follow-up to #54437 that makes test-host handshake failures more discoverable. The reporter now records every handshake failure, re-prints a "Handshake failures:" recap at the end of the run, and fixes the summary precedence so a handshake-only failure no longer prints "Zero tests ran" as the headline.

Changes:

• Track handshake failures in a lock-guarded list and append a recap section after the test run summary.
• Reorder summary branches so anyTestFailed || anyAssemblyFailed takes precedence over allTestsWereSkipped.
• Add a new localized HandshakeFailuresHeader resource (resx + 13 xlf) and extract CapturingConsole into a shared test helper with new coverage.

Show a summary per file

File	Description
src/Cli/dotnet/Commands/Test/MTP/Terminal/TerminalTestReporter.cs	Records handshake failures, emits end-of-run recap, fixes summary precedence, reworded defensive comment.
src/Cli/dotnet/Commands/CliCommandStrings.resx	Adds HandshakeFailuresHeader string with translator comment.
src/Cli/dotnet/Commands/xlf/CliCommandStrings.*.xlf (13 files)	Regenerated xlf entries with state="new".
test/dotnet.Tests/CommandTests/Test/CapturingConsole.cs	Extracted shared IConsole test double.
test/dotnet.Tests/CommandTests/Test/TerminalTestReporterTests.cs	New tests covering recap, multiple failures, no-failure path.
test/dotnet.Tests/CommandTests/Test/TestApplicationHandlerTests.cs	Removes the now-shared inner CapturingConsole.

Copilot's findings

• Files reviewed: 18/18 changed files
• Comments generated: 0

[Youssef1313]

I won't be able to review all the changes here, but worth getting some review from @nohwnd.

[Youssef1313]

I prefer to see integration tests instead of unit tests.

The integration test could try to simulate the scenario by having a custom test host controller extension that crashes or whatever it was that gets us in the bad state. I would like to see the E2E behavior, preferably have a "before" and "after" views.

[nohwnd]

Seconding this.

[Evangelink]

Thanks @Youssef1313 and @nohwnd for the feedback! Addressed in 31f0c99.

Changes:

• Removed the three recap-related unit tests in TerminalTestReporterTests (TestExecutionCompleted_AfterHandshakeFailure_ReprintsFailureDetailsAtEndOfRun, …_WithMultipleHandshakeFailures…, …_WithNoHandshakeFailures…).
• Extended the existing integration test GivenDotnetTestRunsConsoleAppWithoutHandshake (Debug+Release) to assert on the new user-visible behavior end-to-end via dotnet test against ConsoleAppDoesNothing:
  • stdout contains the Handshake failures: recap header,
  • the recap section identifies the failing assembly (ConsoleAppDoesNothing),
  • the summary headline reads Failed! and not Zero tests ran (scoped to the summary line only, since the inline per-assembly progress can legitimately still show Zero tests ran because zero tests really did register).

Captured stdout from a green run on my box:

》Q:\…\ConsoleAppDoesNothing.dll (net11.0) Zero tests ran
》Exit code: 0
》
》Test run summary: Failed!
》  error: 1
》
》  total: 0
》  failed: 0
》  succeeded: 0
》  skipped: 0
》  duration: 163ms
》Test run completed with non-success exit code: 1 (see: https://aka.ms/testingplatform/exitcodes)
》
》Handshake failures:
》  Q:\…\ConsoleAppDoesNothing.dll (net11.0)
》Exit code: 0

Kept as defensive unit tests (cannot be exercised E2E):

• TerminalTestReporterTests.AssemblyRunCompleted_WhenExecutionIdUnknown_DoesNotThrowAndReportsHandshakeFailure — guards an unreachable back-stop branch inside TerminalTestReporter.AssemblyRunCompleted that the normal handler routing never hits.
• TestApplicationHandlerTests.OnTestProcessExited_WhenOnlyControllerHandshakeReceived_RoutesToHandshakeFailureWithModuleContext — pins the controller-only handshake routing decision from Handle assemblies gracefully #52308 (the exact scenario you called out). Avoids needing a bespoke "controller crashes mid-handshake" test asset, which would depend on MTP internals and be brittle to crash at exactly the right moment.

Let me know if you'd still like a dedicated controller-crash test asset; happy to add one if you think the routing-level unit test isn't enough.