vstest: Show the test which crashed the test run (test explorer)

(Created from #623)

Description

Certain crashes make the test runner implode. I’m working on a refactoring and when I run tests sometimes this happens:

 The active test run was aborted. Reason: Unable to communicate with test host process.

Which probably means the process crashed but the test runner doesn’t help me diagnose things here. I don’t know which test was running when it crashed, so I have to manually binary search until I find the one that is the culprit.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 23
  • Comments: 34 (20 by maintainers)

Most upvoted comments

@petarrepac sorry, there isn’t a plan to back port the fix to dotnet-cli 1.0 at this time.

@Zimmergren don’t have an exact date that I can share, a build should be available in next couple of weeks 😃

This is fixed in latest dev builds of dotnet-cli 2.0.0-preview1-005963. Download it from https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.0.0/dotnet-dev-win-x64.latest.zip.

We have also fixed it for VS. Will update when a build with fix is available.

Note: issue will show for netcoreapp2.0 due to https://github.com/dotnet/cli/issues/6535.

Verified in VS15.3.0 preview1.0 [26526.3005.d15prerel].

+1. Here’s a simple test that is hard to debug because vstest swallows the error:

        [Fact]
        public void Fails()
        {
            Action fail = () => Debug.Assert(false, "Oops");
            var thread = new Thread(new ThreadStart(fail));
            thread.Start();
            thread.Join();
        }
$ dotnet test

Starting test execution, please wait...
[xUnit.net 00:00:00.4543872]   Discovering: repro
[xUnit.net 00:00:00.5895954]   Discovered:  repro
[xUnit.net 00:00:00.6358530]   Starting:    repro
The active test run was aborted. Reason: Unable to communicate with test host process.

In contrast, using a console app or dotnet-xunit will correctly print to console the Debug.Assert failure.

$ dotnet xunit
Running .NET Core tests for framework netcoreapp2.0...                                                                   
xUnit.net Console Runner (64-bit .NET Core 4.0.0.0)                                                                      
  Discovering: repro                                                                                                     
  Discovered:  repro                                                                                                     
  Starting:    repro                                                                                                     
                                                                                                                         
Unhandled Exception: System.Diagnostics.Debug+DebugAssertException: Oops                                                 
                                                                                                                         
   at System.Diagnostics.Debug.Assert(Boolean condition, String message, String detailMessage)                           
   at repro.Test.<>c.<Fails>b__0_0() in C:\tmp\2.0fail\repro\Test.cs:line 13                                             
   at System.Threading.Thread.ThreadMain_ThreadStart()                                                                   
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)   
   at System.Diagnostics.Debug.ShowAssertDialog(String stackTrace, String message, String detailMessage)                 
   at repro.Test.<>c.<Fails>b__0_0() in C:\tmp\2.0fail\repro\Test.cs:line 13                                             
   at System.Threading.Thread.ThreadMain_ThreadStart()                                                                   
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)   

Is there any progress on this? This is one of the most annoying things about working with the new test runner.

Is there a reason that this isn’t the default?

@codito No, we need to see the actual output of the error. Consider the case that several tests together get into a state that crash the process. We want to see the actual stack trace /error that caused it. Right now the error is going into the void.