System.AggregateException was unhandled is thrown

[Michael Korin]

Hello,

Hope someone can either tell me what I am doing wrong, or confirm if this is a bug.

Here is a very simple test case

[Test]

public async Task EqualToTest()

{

   Assert.That(5, Is.EqualTo(6));

}

I know async should not be here. But my real test actually uses async calls, therefore I need that async keyword.  This is just for demonstration purposes

If I run "Run Selected Tests", I will get a correct error  "Test Failed" ...

But, if I run "Debug Selected Tests", I will get

"An exception of type 'System.AggregateException' occurred in mscorlib.dll and wasn't handled before a managed/native boundary

Additional information: One or more errors occurred."

if I remove async, it will work fine.  If do this

Assert.That(5, Is.EqualTo(5));

it will work fine.

So the issue is, ONLY if my test case is async, ONLY if I run it in Debug and ONLY if EqualsTo would fail.

I am using

- Visual Studio 2015 Community Edition

- Framework 4.0 with packages for async calls

- nUnit 3.0.1

- I have nUnit Adapter 3 installed.

[constructor]

My VS2013 shows next error:

[Michael Korin]

Can anyone else confirm if this issue is reproducible or not?  Is it something with my setup or a bug in nUnit?

[Johan Appelgren]

Where do you get this error? In the test report?

[Michael Korin]

This error comes in Visual Studio as Source Not Found and Exception.

See attached image.

On Wednesday, 24 February 2016 16:58:09 UTC-5, Johan Appelgren wrote:

[Michael Korin]

I thought initially that it was only related to EqualTo method, but it is not.  If I run this, I get the same error:

Assert.That(false, Is.True);

[Johan Appelgren]

You've most likely configured Visual Studio to break when an exception crosses an AppDomain or managed/native boundry.

To turn that off uncheck:

Tools -> Options -> Debugging -> General -> "Break when exceptions cross AppDomain or managed/native boundries (Managed Only)".

If you need it enabled then you just have to press continue in these cases.

/Johan

[Michael Korin]

Hi,

 

I don’t have this exception selected.  If you see my screenshot, you will see that this checkbox is unselected.  It was confirmed that this is a bug in nUnit.  It might be an issue in Adapter or framework itself.

 

 

Regards,

 

Michael

--
You received this message because you are subscribed to a topic in the Google Groups "NUnit-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nunit-discuss/8dDZMNZoPa8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nunit-discus...@googlegroups.com.
To post to this group, send email to nunit-...@googlegroups.com.
Visit this group at https://groups.google.com/group/nunit-discuss.
For more options, visit https://groups.google.com/d/optout.

[Charlie Poole]

Hi Michael,

Can you explain "it was confirmed that this is a bug in nunit?" There
is no bug accepted or even proposed that I can find.

I don't want you to be sitting back and waiting for us to fix
something we are not working on!

Charlie

> You received this message because you are subscribed to the Google Groups
> "NUnit-Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Johan Appelgren]

Have you checked that option in Visual Studio Options? This is different from the break on exception setting that you can configure per exception type.

[Michael Korin]

I posted this on nUnit issues: https://github.com/nunit/nunit3-vs-adapter/issues/127.


Regards,

Michael

[Michael Korin]

Johan,

You are correct, once I disabled this option, AggregateException is not thrown up anymore.

But now, debugger does not stop where the Assert throws because of failure.

For example, if I have a regular test case like below and run a test in a debug mode, with the option enabled, the program would break on a line Asset.That(y, Is.True) with AssertionException was unhandled error. This points exactly which assert fails allowing to analyze results and figure out why it fails. By disabling this option, debugger does not break and exits this test case. So this is same thing as executing test in non-debug mode.
[Test, Category("nUnit Experiment")]
public void IsTrueTest()
{
int x = 6;
int y = 7;
bool result = x == y;
Assert.That(y, Is.True);
}
I know you can put a break and then go line by line. Then when you hit the assert line that fails execute does not pause. Now you have to run the test case again and pause before that assert to analyze all results.

So now I am disabling this for all test cases regardless if it is async or not.

Maybe there are some additional options can be configured?

Regards,

Michael

-----Original Message-----
From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com] On Behalf Of Johan Appelgren
Sent: Monday, February 29, 2016 11:25 AM
To: NUnit-Discuss <nunit-...@googlegroups.com>

[Charlie Poole]

Hi Michael,

Sorry, I had my NUnit ht on and so was looking for an issue on the
NUnit project rather than the VS Adapter project. The issue you posted
is indeed listed and I have posted comments there as well.

The issue is still shown as requiring confirmation - that's what
status:Confirm means. So far, based on the discussion, it appears not
to be an NUnit issue but it still needs to be investigated as an
adapter issue.

Charlie

[Greg Young]

This sounds like expected behaviour of VS.

A quick google around async + aggregateexception and its a top hit :)

"For example, if I have a regular test case like below and run a test
in a debug mode, with the option enabled, the program would break on a
line Asset.That(y, Is.True) with AssertionException was unhandled
error. This points exactly which assert fails allowing to analyze
results and figure out why it fails. By disabling this option,
debugger does not break and exits this test case. So this is same
thing as executing test in non-debug mode."

It is not the same (the debugger is still attached). You can also more
finely grained specify which type of exceptions to stop on when
*thrown*. Note that your exceptions are being handled you just are
playing with the settings of when to automatically break.

Greg

Studying for the Turing test