Exception message is "TestDelegate" when using Throws.Nothing.After

[JackUkleja]

Could someone explain the following behaviour to me? (assuming it is not a bug...). When using the DelayedConstraint

Assert.That(() => {throw new Exception("hello");}, Throws.Nothing.After(100));
Outputs:

Expected: No Exception to be thrown after 100 millisecond delay
But was: <NUnit.Framework.TestDelegate>

Assert.That(() => {throw new Exception("hello");}, Throws.Nothing);
Outputs:

Expected: No Exception to be thrown
But was: <System.Exception: hello
at ...

I expect both to output the second message.

[CharliePoole]

Use of After with Throws makes no sense but if it is allowed should give better output.

My preference would be to fix this by making After unavailable on this constraint at compile time. If that can't be done, then the message should say it's an error to use it here.

[JackUkleja]

Can I ask why you say it makes no sense?

Because what we are trying to do in our test is ensure that after a certain amount of time, a method stops throwing (if you are curious why it's because we are using NSubstitute to verify calls - and until the call has been verified it will throw).

It seemed Throws.Nothing.After would be appropriate, and seems to be working for us.

[CharliePoole]

So each time the method is called, you would want it to succeed if no exception is thrown but just keep on trying if one is thrown, finally only failing after the time is up? That would be consistent with how After usually works, although not consistent with how we generally handle exceptions. 😄

What if you used Throws().After ? Should that be allowed?

[JackUkleja]

Yes this may not be consistent with how we generally handle exceptions but it's how the NSubstitute API works. There are alternatives - we could do our own polling check to check the call is received, or we could wait on something else before making the call. But the NUnit delayed constraints framework seems nice for many of these threading/time based tests hence why I was trying to use it.

TBH yes I would expect Throws.After to work as well. Anything you might want to verify with an immediately evaluated constraint I think makes just as much sense to work with a delayed constraint :-/

[CharliePoole]

Yes, it makes some sense. We will have to override the general implementation of After for those particular constraints.