Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InnerException's are lost in the Testing Platform output #3783

Open
thomhurst opened this issue Sep 7, 2024 · 2 comments · May be fixed by #3920
Open

InnerException's are lost in the Testing Platform output #3783

thomhurst opened this issue Sep 7, 2024 · 2 comments · May be fixed by #3920
Assignees

Comments

@thomhurst
Copy link
Contributor

Just been wrapping some exceptions to provide more context to users (e.g. A TearDown method failed, etc.) and noticed that the output is losing some context - And makes it almost impossible for a user to see where an actual crash was.

Reproduction: Wrap some exceptions in a new exception where the original exception is passed in as an InnerException.

Throw your wrapped exception, and you won't see any message or stacktrace from your original exception in the testing platform output.

Repro code:

using Microsoft.Testing.Extensions;
using Microsoft.Testing.Platform.Builder;
using Microsoft.Testing.Platform.Capabilities;
using Microsoft.Testing.Platform.Capabilities.TestFramework;
using Microsoft.Testing.Platform.Extensions.Messages;
using Microsoft.Testing.Platform.Extensions.TestFramework;
using Microsoft.Testing.Platform.TestHost;

var builder = await TestApplication.CreateBuilderAsync(args);
builder.RegisterTestFramework(_ => new TestFrameworkCapabilities(), (_, _) => new DummyAdapter());
var app = await builder.BuildAsync();
return await app.RunAsync();

internal class DummyAdapter() : ITestFramework, IDataProducer
{
    public string Uid => nameof(DummyAdapter);

    public string Version => string.Empty;

    public string DisplayName => string.Empty;

    public string Description => string.Empty;

    public Type[] DataTypesProduced => new[] { typeof(TestNodeUpdateMessage) };

    public Task<CloseTestSessionResult> CloseTestSessionAsync(CloseTestSessionContext context) => Task.FromResult(new CloseTestSessionResult { IsSuccess = true });

    public Task<CreateTestSessionResult> CreateTestSessionAsync(CreateTestSessionContext context) => Task.FromResult(new CreateTestSessionResult { IsSuccess = true });

    public Task ExecuteRequestAsync(ExecuteRequestContext context)
    {
        try
        {
            MyService.DoSomething();
        }
        catch (Exception e)
        {
            context.MessageBus.PublishAsync(this, new TestNodeUpdateMessage(new SessionUid("1"), new TestNode()
            {
                Uid = "2",
                DisplayName = "Blah",
                Properties = new PropertyBag(new FailedTestNodeStateProperty(e))
            }));
        }
     
        context.Complete();
        
        return Task.CompletedTask;
    }

    public Task<bool> IsEnabledAsync() => Task.FromResult(true);
}

public class MyService
{
    public static void DoSomething()
    {
        try
        {
            InnerDoSomething();
        }
        catch (Exception e)
        {
            throw new WrappedException("Service failed!", e);
        }
    }

    private static void InnerDoSomething()
    {
        throw new Exception("Error code 488");
    }
}

public class WrappedException(string message, Exception innerException) : Exception(message, innerException);

Actual output:

failed Blah (0ms)
  Service failed!
  Stack Trace:
    at MyService.DoSomething() in C:\git\TestPlatformSingleFileCoverageExceptionRepro\TestPlatformSingleFileCoverageExceptionRepro\TestPlatformSingleFileCoverageExceptionRepro\Program.cs:64
    at DummyAdapter.ExecuteRequestAsync(ExecuteRequestContext context) in C:\git\TestPlatformSingleFileCoverageExceptionRepro\TestPlatformSingleFileCoverageExceptionRepro\TestPlatformSingleFileCoverageExceptionRepro\Program.cs:34

Expected:

To include the message of Error code 488 and the stacktrace location of MyService.InnerDoSomething on line 70 of the original exception.

@thomhurst
Copy link
Contributor Author

Any chance we could get this triaged and fixed? Not being able to see exceptions and stack traces seems like a pretty big deal and one that can really limit fixing tests

@Evangelink
Copy link
Member

Hey @thomhurst,

Thanks for the ping and sorry this got missed. I am on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants