Visual Studio "Debug Unit Test" fails to hit breakpoints

Question

When using Visual Studio 2008 and debugging my unit tests... sometimes the debugger works fine. However very often after modifying some code then clicking "Debug Unit Test" Visual Studio will fail to hit the breakpoints in the code. The debugger basically hangs and eventually the tests runs with the new code anyway, but never stops to let me see what is going on.

I'm assuming this has something to do with some type of assembly caching done by the debugger, but not matter what I do (clean project, delete bin folders, restart VS, etc) I can never get the right assembly to load. Has anyone else seen this behavior? Any solutions?

By the way, using Resharper 4.5, and .NET 3.5 on Win XP.

Unbelievable

Check your test project's referenced assembly's locations! – Snafu

It references the project with the code changes directly. – Unbelievable

I am seeing the same behavior in VS2010 :( – Pauwles

Also happened to me in VS2010, however doing a clean solution seemed to fix things – Unbelievable

Same problem in VS2013 with ReSharper. I commented the test, problem for future me. – Brady

Using Resharper 10 in VS 2013. This was never a problem before, but after re-imaging my machine, I have one solution that ALWAYS does this. I'm sure it has something to do with the cached shadow copy. If I make any code changes and set any new breakpoints, they won't get hit the first time. I have to let it fail or kill it, and do it a second time. The breakpoints always get hit the second time. I'm thinking it must be some setting because it only happens on my machine and (I think) only for this one solution. – Detonate

VS restart usually helps. :S – Mohr

Related post - Visual Studio 15.8.1 not running MS unit tests – Mump

Does this answer your question? Visual Studio - suddenly cannot debug tests – Bond

My issue was with passing int inline data for decimal parameters. This fixed it for me: https://mcmap.net/q/267166/-how-can-i-pass-values-to-xunit-tests-that-accept-a-nullable-decimal – Keifer

Answer 1

I just had a problem hitting breakpoints in VS2015.

I am always using the solution configuration called Debug but for some reason my solution was set to build the Release version.

Switching from Release to Debug in the dropdown at the top of Visual Studio fixed my problem.

Despondency

So blooming obvious when you notice that. Thank you! :) – Quezada

I have actually made the same mistake again last week. I usually never switch to release build, but a few old solutions are not deployed by the build server so I have to build the solution in release mode locally. And then I forget to switch back. – Despondency

Yeh, same here. I usually always keep it in Debug too. I was Googling everything around Nunit, Resharper and Nunit Tet Runner....didn't realise the problem was a silly drop down box! Thanks again – Quezada

Answer 2

I've solved the similiar problem on VS2022 with test project using xunit by deleting launch settings file.

..\Properties\launchSettings.json

Hjerpe

This fixed the issue immediately for me as well! Had a weird WSL launch profile on the test project for some reason. – Stygian

This was mine too. No idea where this came from. – Minardi

I commented the default profile in this file and it started working – Groh

Answer 3

Right click + Run Test(s) will not hit the breakpoint.

Right click + Debug Test(s) will!

Underwood

Thank you! I feel dumb now, I've been chasing this like 20 minutes! – Canvass

@BillyWilloughby, you're welcome, I felt the same – Underwood

True that "run tests" not should debug tests but regardless of what I am choosing, the debugger fails to attach. – Brickle

Answer 4

Another workaround: Force the debugger to be launched from within your unit test:

System.Diagnostics.Debugger.Launch();

Mephitis

Turns out my test file had other issues. I might write up my own answer... – Overskirt

After I added this, the breakpoint in question was hit. Afterwards, I removed this line and the breakpoint still continued to be hit... Some voodoo mix going on there. – Plaid

@JamesJohnMcGuire'Jahmic': Was the project really built after removing that line? Maybe the exe/dll was still in use and could not be written by VS. Rebuild it and watch the compiler output window! You can also surround it by conditional compile with #if DEBUG ...code... #endif to ensure it's removed from the release version. – Mephitis

@Mephitis - You may be onto something. It was a while ago, but if I come to this situation again, I will check more carefully. – Plaid

Answer 5

One problem that I stumbled upon when trying to debug a test method was that it was private. Simply changing the method from private to public fixed my problem.

I don't know why this is a problem, but it probably has something to do with the implementation of the [Test] attribute of NUnit.

Semicentennial

wow. Thanks for that. I had created a new class which by default as not marked "public". Once I added that, it worked. Your answer made me think to check. – Parisian

Please make sure you also have TestCleanUp or InitializeTest methods public :) – Insincerity

Answer 6

Very late in the day, but in case anyone else ends up here like I did....

My tests would not hit a breakpoint. I went to bare bones in the test (below) but still not hitting:

    [Fact] // xunit, c#, vs 16.9.0
    public void TestX()
    {
        var messages = new List<int>();
        Assert.NotNull(messages);
    }

Copied the same test to a different project, hit the breakpoint straight away.

Tried a few things, then spotted the problem...

In my original test project, I referenced the SUT project, which had the following SDK package reference copied from the SUT:

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.11" />

Once I removed this on my test project, breakpoints were being hit again!

Frustrating and wasted time that I didn't have, so hopefully helps someone else!

Ishii

This did it for me. I have the Functions SDK installed on the test project. That's what I get for installing the nuget package from the solution side and selecting all projects. If you're working on a azure function project make sure this nuget package isn't included in your xunit test project. – Botulinus

Thanks @GregoryBillings - glad it helped you out. Frustrated me at the time:) – Ishii

Answer 7

What happened to be the solution for me: make sure all your nuget package versions match. My Unit Test project was using a version of Newtonsoft.Json that was newer than the Newtonsoft.Json reference on the project I was testing. Once I updated all nuget packages to the latest version I was able to hit the breakpoint

Freesia

That nailed it for me! – Parisian

Answer 8

Now we have this problem with Visual Studio 2017 15.5 and Resharper 2017.2. Problem caused by Resharper and solved in latest versions 2017.3+

link

Inextirpable

This fixed it for me running VS 2017 v15.5.6 – Hamitosemitic

Answer 9

For me I went to Test explore -> setting -> processor Architecture For AnyCPUProjects and changed it to X64 and it worked for me.

Hiatus

Answer 10

I had the same problem, although I don't have permanent solution, this is a quick one time fix: Debug the unit test (Ctrl-T, Ctrl-D), then go to "Immediate Window", enter anything (e.g. 'a' or null) and press enter. After this the break point will be hit.

Fleck

Did not work for me. – Brickle

Answer 11

The breakpoint is not hit when starting debugging from the "Unit Test Sessions" window (Resharper - Windows - Unit Test Sessions) which comes from ReSharper.

But when starting the test from the "Test Explorer" window (Test - Windows - Test Explorer) of VS it hits the breakpoint.

VS Enterprise 2017 V15.5.6, ReSharper 2017.2.2

The latest ReSharper 2017.3.1 is not an option because it has other bugs

Mephitis

Answer 12

Ensure [TestMethod] attribute is present for the method, [TestClass] is present for class.

Anadem

Answer 13

Check the solution Configuration Manager to see if your Unit Tests project is checked to be built with your current settings.

When you click "Run" or "Debug", VS builds your solution again, however it might skip the Unit Tests project. If you made any changes after the last build, they won't be reflected during the testing, and as the source code changed, the debugger can't hit your breakpoints.

Fullmouthed

Answer 14

If you have [HostType("ASP.NET")], remove it and Test -> Debug -> Run your tests again

Ovule

Answer 15

Make sure you are debugging the correct test!

I have some tests with very similar names except for the last word in the test name. I had the break point set in the first test and was using Visual Studios "Test Explorer" window to "Debug Selected Tests" on the second test, which didn't have a breakpoint set.

Test names

PublishAsync_Valid_Acked
PublishAsync_Valid_Nacked

Fatigued

Answer 16

If you are using a setup method with [TestInitialize] \ [ClassInitialize] attribute (mstest \ nunit)? try to check if that setup code is being executed successfully.

For example:

[TestInitialize]
public void Setup()
{
    throw new Exception();
}

[TestMethod]
public void SomeFooTest()
{
    //The breakpoint will "Fail" to hit here.
}    

---

In visual studio you can easily see this behavior with Test Explorer or by the CodeLens (only in professional):

Dinka

Answer 17

Reference the nuget package xunit.runner.visualstudio into your test project.

I had the same scenario, none of the above mentioned suggestions worked for me.Then I referenced a nuget package xunit.runner.visualstudio and the issue is solved

Izmir

Answer 18

I got another possible solution - Check for exceptions thrown "silently".

I'm using VS 2019 Professional. I opened Test Explorer, clicked my desired test and chosen "Debug" (had a breakpoint in the test itself). The breakpoint was not hit. I kept looking for answers in the "Tests" output window, but there was only info, that the test has run and finished (failed).

Then I discovered that clicking on the single test in Test Explorer and looking down, there's "Test Detail summary" and voila. The message there said, there's an exception thrown inside the test. I fixed the problem causing this exception and it started hitting. The tricky thing was, that I didn't know about the exception, there was no other notification than the one in Test detail summary.

Dissert

Answer 19

After having wasted almost half an hour trying to find the problem, I checked the Symbols settings (VS Menu -> Tools -> Options -> Debugging -> Symbols) and cleared all custom settings.

• I ensured 'Load all Modules, unless excluded' and cleared the custom list.
• Emptied symbol cache

After that it started working as usual.

Billiton

Answer 20

In my case, updating Visual Studio to the latest version solved the issue.

Version 17.2.3 didn't work.

Version 17.3.1 works.

Torticollis

Answer 21

I ran into this problem in VS2019 when trying to debug my native code unit tests, which were created following the instructions in https://learn.microsoft.com/en-us/visualstudio/test/how-to-use-microsoft-test-framework-for-cpp?view=vs-2022

• I changed the project debugging properties to launch TestExplorer directly: in "Configuration / Debugging", setting "Command" to $(DevEnvDir)\CommonExtensions\Microsoft\TestWindow\vstest.console.exe and "Arguments" to $(TargetPath)

• Another problem was that the unit test project was not set to create a PDB file, so check your project properties, in "Linker / Debugging / Generate Debug Info": it should be set to Yes /DEBUG.

Widdershins

Answer 22

For me, the issue was that I was passing int inline data to decimal parameter.

For eg:

[Theory]
[InlineData("SomeString", 1, 2)]
public void Should_Do_Something(string someStr, decimal? someDecimal, decimal expectedDecimal)
{
    // Arrange
    // Act
    // Assert
}

This is how I fixed it:

[Theory]
[MemberData(nameof(DoSomethingTestData))]
public void Should_Do_Something(string someStr, decimal? someDecimal, decimal expectedDecimal)
{
    // Arrange
    // Act
    // Assert
}

public static IEnumerable<object[]> DoSomethingTestData()
{
    var allData = new List<object[]>
    {
        new object[] { "SomeString", 1M, 2M },
        new object[] { "SomeOtherString", null, 1M } // etc.
    };

    return allData;
}

Keifer

Answer 23

None of these worked for me. I saw that there was "launchSettings.json" in the Properties folder of the test project. I deleted that, and debug now works.

Unexceptional

Answer 24

In my case, I had started learning the tests with Console app, and when I started learning Fake, I injected services in the test constructor (because I am used to this) and I stayed for a whole day searching and I did not find any answer to what is happening with me! The solution: Delete anything within the test constructor because you may be used to injecting services in it :)

Retiary