Failing Debug Tests do not break into debugger in VS

Bug #1210535 reported by Richard Lawley
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
NUnit Test Adapter
Triaged
High
Unassigned

Bug Description

When Debugging a failing synchronous unit test, Visual Studio will break into the debugger as the Exception is thrown (with break on exceptions set to User-Unhandled). However, with an async nunit test, it looks like the exception is being swallowed by the test runner and does not cause VS to break. Setting break on exceptions to "Thrown" WILL cause it to break.

Sample Code:

    [TestFixture]
    public class SampleFixture
    {
        [Test]
        public async Task AsyncTest()
        {
            Assert.Fail();
        }

        [Test]
        public void SyncTest()
        {
            Assert.Fail();
        }
    }

Instructions to reproduce:

* Start a new Class Library project in Visual Studio (tested under 2012 and 2013 Preview, tested with Framework 4.5 project).
* Add the above code as a class
* Build the project
* Ensure "Break on Exceptions" is set to "User-Unhandled" for "Common Language Runtime Exceptions"
* Right click "SyncTest" in Test Explorer, click "Debug Selected Tests". Visual studio will automatically break at the Assert.Fail line.
* Right click "AsyncTest" in Test Explorer, click "Debug Selected Tests". Visual Studio will go into debug mode, and finish immediately without breaking into the debugger. Test failure will still be recorded in the Test Explorer.

Tags: github
Revision history for this message
Richard Lawley (richard-v) wrote :

(Tested on Visual Studio 2012 and 2013 Preview, using latest Test Adapter from Gallery - 0.96.0.4, and using nunit from nuget)

Changed in nunit-vs-adapter:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Richard Lawley (richard-v) wrote :

Are you sure this is related to the other bug? Because VS breaks into debug if Break on Exceptions is set to Thrown instead of User-Unhandled, is it possible that this is nunit catching and swallowing an exception?

If it is related, then that's fine :)

Revision history for this message
Charlie Poole (charlie.poole) wrote :

Good point. I'll remove the duplicate status.

Revision history for this message
Charlie Poole (charlie.poole) wrote :

There's a good chance this is an NUnit bug and that we can't do anything about it in the adapter. We'll have to set up a test running the NUnit console or gui runner under the debugger.

Revision history for this message
Charlie Poole (charlie.poole) wrote :

Moved to https://github.com/nunit/nunit-vs-adapter/issues/2 and marked Won't Fix here.

Changed in nunit-vs-adapter:
status: Triaged → Won't Fix
Changed in nunit-vs-adapter:
status: Won't Fix → Triaged
tags: added: github
Revision history for this message
Terje Sandstrom (b-tfrje-j) wrote :

See comment on github : https://github.com/nunit/nunit-vs-adapter/issues/2

Can't repro this.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.