CODEWITHSUNDEEP
asp.netunit-testing
Foster Hao
Foster Hao

Reputation: 132

Assert faild exception was not handled in user code

when I made an unit test and there is an exception as below, can any one tell me what's wrong with this:

An exception of type 'Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException' occurred in Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll but was not handled in user code

Upvotes: 4

Views: 9126

Answers (3)

SMiller
SMiller

Reputation: 93

I had this problem in Visual Studio 2012. Here's how I fixed it:

In the exception pop up, I had a checked box next to "Break when this type of exception isn't user-handled."

I unchecked the box.

Sometimes it's the simple things that get you. :)

Update 1 year later :)

So this doesn't pertain to this particular question, but I learned another trick to hide exceptions that are thrown by non-Microsoft .dll's. (Assert.Failed is inside one of the System libraries, so the OP wouldn't need to use this trick.)

You may have noticed that some exceptions mysteriously continue to break when unhandled, even when you uncheck the "Break when this exception type is thrown" box.

There is a reason for this! Visual Studio doesn't know how to recognize that Exception type.

Here's how to teach it a new trick:

  1. Get the full exception name, with all of its namespacing. For example, you'll need "MySql.Data.MySqlClient.MySqlException", not just "MySqlException". Click "View Detail" in the exception popup to get this information.
  2. Go to the DEBUG menu -> Exceptions.
  3. Click the "Add...." button.
  4. In the popup that appears, pick a sub-grouping that you'd like to add your new exception to. For MySql, I used "Common Language Runtime Exceptions", but pick whichever group makes sense to you. I don't believe you can add your own, unfortunately.
  5. For the exception name, enter the fully qualified exception name that you found in step 1.
  6. Save, and then uncheck the "Thrown" box for your shiny new exception!

Once you've added your exception, you'll also be able to use the "Break when this exception is thrown" checkbox in the popup again.

Happy coding!

Upvotes: 9

Ylenia88m
Ylenia88m

Reputation: 83

I had this problem and I found a link that may help.

There’s something a little peculiar about how unit tests work in Silverlight when the debugger is attached – when an Assert fails in one of your unit tests, the Visual Studio debugger breaks the execution and brings up the debugger dialog. If you want to run a whole bunch of unit tests to see which ones are failing or you only care about the exceptions that your code throws, this feature can really cramp your style. Thankfully, it’s pretty easy to edit the debugger settings to make these Assert exceptions go away.

  • Step #1: Go to the Debug menu in Visual Studio 2010, choose Exceptions…
  • Step #2: On the Exceptions dialog, click Add…
  • Step #3: Register the exception types you want to tweek From the Type menu, choose Common Language Runtime Exceptions. In the Name textbox, type Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException. Click OK.
  • Step #4: Repeat step #2 and #3 for Microsoft.VisualStudio.TestTools.UnitTesting.AssertInconclusiveException
  • Step #5: Uncheck Thrown and User-unhandled for the exceptions you just added.
  • Step #6: On the Exceptions dialog, click OK
  • Step #7: Enjoy your new streamlined exceptions.

However in my case I had it because of a conflict between using an assert that belongs to the unit test library while also using a nunit one. when I removed that conflict my tests work as expected.

Upvotes: -1

TGH
TGH

Reputation: 39268

What version of MS Test are you using (which Visual Studio)?

Are you debugging when the exception is thrown?

Looks like there is an article here with some clues about why this is happening:

http://connect.microsoft.com/VisualStudio/feedback/details/511897/expectedexception-still-causes-debugging-to-break-with-exception-was-unhandled-by-user-code

Upvotes: 2

Related Questions