ThrowsAsync<T> doesn't ensure that the thrown Exception is of type T

[jackofcoding]

Preamble

The current latest version (0.25.6) suffers from this, as does 0.22.31, but version 0.22.24 does not suffer from this.
It therefore seems to have been introduced with the 0.22.31 release.
I would assume that #2479 is the cause of this.

Reproduction

public class Foo
{
  private void ThrowsArgumentException() => throw new ArgumentException("Just for testing");

  [Test]
  public async Task ThrowsAsync_DoesNotCheckType()
  {
    var exception = await Assert.ThrowsAsync<OverflowException>(LocalTestFunction);
    await Assert.That(exception).IsNotNull();
    await Assert.That(exception.Message).IsEqualTo("Just for testing");
    await Assert.That(exception).IsTypeOf<OverflowException>();
    return;

    Task LocalTestFunction()
    {
      ThrowsArgumentException();
      return Task.CompletedTask;
    }
  }
}

Result with 0.22.24

AssertionException: Exception is of type ArgumentException instead of OverflowException for LocalTestFunction
Exception doesn't have a stacktrace

Result with 0.22.31 onwards (including 0.25.6)

AssertionException: Expected OverflowException but received ArgumentException
Exception doesn't have a stacktrace

Expectations

1. I think it's fair to expect that exception will be of type OverflowException or the method fails.
   This is an assertion after all, and I don't expect exception to actually be ArgumentException!
2. As you can also see with version 0.22.31 onwards, it's the custom assertion on type that is the one that fails.
   When using generics, you expect that type, so this assertion shouldn't even have to be there, I guess.
3. Some documentation around ThrowsAsync, as I couldn't find any on https://tunit.dev/docs
   Or maybe my search skills are lacking, but exception and ThrowsAsync don't find anything.
   Because I figured my brain was fooling me at first, but only when I started digging, I saw the behavior I expected/thought was there all along.

[thomhurst]

I'm not sure I quite understand. The exception message has changed slightly, but the logic is still the same?

Expected OverflowException but received ArgumentException

vs

Exception is of type ArgumentException instead of OverflowException

Both of these mean the same thing just different wording. And an error is still successfully thrown for both. So I don't quite understand what the bug is?

[jackofcoding]

The issue is that the error you see raised comes from the type assertion I had to add manually. Without that assertion I added myself, the test will succeed, even though there's a type mismatch. In other words, I expect ThrowsAsync to do the type assertion for me, and only return an Exception when it can actually cast to the type requested. If it can't, execution should stop there I would say (in this example).For obvious reasons I want to unit test the interface of my codebase. This includes exceptions. If I were to change one, I expect unit tests to fail.I hope this makes it more clear. If not, I'll add an example where the test says pass, but obviously the test should fail. On 10 Jun 2025 02:17, Tom Longhurst ***@***.***> wrote:thomhurst left a comment (thomhurst/TUnit#2538) I'm not sure I quite understand. The exception message has changed slightly, but the logic is still the same? Expected OverflowException but received ArgumentException vs Exception is of type ArgumentException instead of OverflowException Both of these mean the same thing just different wording. And an error is still successfully thrown for both. So I don't quite understand what the bug is? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[thomhurst]

Got ya! I found the issue. Fix out shortly.

[jackofcoding]

Awesome! I also dug a bit in that pull request, but I didn't spot it as fast to be confident to make a suggestion for you.

PS: I'm sorry if I may have come across a bit aggressive, totally not my intention! (I read my text back, and the tone isn't the nicest...)