Assert.Throws should print the actual exception.

[nohwnd]

Summary

 Assert.Throws failed. Expected exception type:<System.ArgumentException>. Actual exception type:<System.InvalidOperationException>. 'action' expression: '() => new MyClass().MyMethod()'.
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.<>c__DisplayClass226_1`1.<IsThrowsFailing>b__1(String userMessage) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:581
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsException[TException](Action action, Boolean isStrictType, String message, String actionExpression, String assertMethodName) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:330
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.Throws[TException](Action action, String message, String actionExpression) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:187
    at mstest306.Test1.TestMethod1() in Test1.cs:9
    at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
    at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
bin\Debug\net10.0\mstest306.dll (net10.0|x64) failed with 1 error(s) (566ms)

is what I see currently when Assert.Throws fails. This is not giving it all the information I need to find the failure, and forces me to guess where the error happened. Am I seeing the friday error, or other error? what if the problem is not easily replicable?

Instead it would be nice if we reported the whole exception, so I can see the message and stack trace of the unexpected exception, and maybe solve this problem without debugging .

// file Test1.cs
namespace mstest306;

[TestClass]
public sealed class Test1
{
    [TestMethod]
    public void TestMethod1()
    {
        Assert.Throws<ArgumentException>(() => new MyClass().MyMethod());
    }
}

public sealed class MyClass
{
    public void MyMethod ()
    {
        Helper.HelperMethod();
    }
}

public static class Helper
{
    public static void HelperMethod()
    {

        if (DateTime.Now.DayOfWeek.ToString() == "Friday")
        {
            throw new InvalidOperationException("the error");
        }   
        else
        {
            throw new InvalidOperationException("the other error");
        } 
    }
}

[Evangelink]

IMO this relates to #6717.

For many assertions, it would be nice it we could print the actual. It could be interesting to consider having the NUnit feature where you can register display/value formatters for the case of testing: https://docs.nunit.org/articles/nunit/writing-tests/TestContext.html#addformatter-32 so we can have a readable display for complex "objects".

We could also fallback to a version where we do some reflection to get the fields/properties and display them kinda like a record (we would need a different syntax not to confuse user with type being a record). We may want to limit the number of state we explore to avoid adding too much perf impact and to avoid taking too much display.

[nohwnd]

I think that is only very causally related, and it will take time (if we even decide to implement it).

Exceptions format themselves in standard way, so we should just call to string on the received exception and show it.

[nohwnd]

Added partial fix to get us there, so we can investigate issues better for internal failure. But my desired state for that assertion (and other assertions, now that we have the expressions) would be to go from this:

failed TestMethod1 (21ms)
  Assert.ThrowsExactly failed. Expected exception type:<System.InvalidOperationException>. Actual exception type:<System.ArgumentNullException>. 'action' expression: '() => MyClass.MyMethod()'.
  from bin\Debug\net10.0\mstest319.dll (net10.0|x64)
  Assert.ThrowsExactly failed. Expected exception type:<System.InvalidOperationException>. Actual exception type:<System.ArgumentNullException>. 'action' expression: '() => MyClass.MyMethod()'.
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.<>c__DisplayClass226_1`1.<IsThrowsFailing>b__1(String userMessage) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:581
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsException[TException](Action action, Boolean isStrictType, String message, String actionExpression, String assertMethodName) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:330
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsExactly[TException](Action action, String message, String actionExpression) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:267
    at mstest319.Test1.TestMethod1() in Test1.cs:9
    at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
    at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

to this:

failed TestMethod1 (21ms)
  from bin\Debug\net10.0\mstest319.dll (net10.0|x64)
  Assert.ThrowsExactly failed. () => MyClass.MyMethod() was expected to throw System.InvalidOperationException, but System.ArgumentNullException was thrown.
    Expected exception type: System.InvalidOperationException
    Actual exception: System.ArgumentNullException: Value cannot be null.
      System.ArgumentNullException: Value cannot be null.
      at mstest319.MyClass.MyMethod() in Test1.cs:18
      at mstest319.Test1.TestMethod1() in Test1.cs:9
        ...
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.<>c__DisplayClass226_1`1.<IsThrowsFailing>b__1(String userMessage) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:581
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsException[TException](Action action, Boolean isStrictType, String message, String actionExpression, String assertMethodName) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:330
    at Microsoft.VisualStudio.TestTools.UnitTesting.Assert.ThrowsExactly[TException](Action action, String message, String actionExpression) in /_/src/TestFramework/TestFramework/Assertions/Assert.ThrowsException.cs:267
    at mstest319.Test1.TestMethod1() in Test1.cs:9
    at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
    at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

(the three dots are not meant to represent shortening of the inner stack trace, I just don't have exact example)

Following this pattern:

<short summary of what failed, without adding multiline details e.g. expanding objects>, so I can see what is the problem before digging into the details. This is up to each assertion to see what is correct. e.g. expanding long strings in the short message is not good. Showing whole error and stack trace before saying "but the message did not match" is also not great.

<details of expected>
<details of actual>

<user message?>

[Evangelink]

I would have user message before details.