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.

Also happened to me in VS2010, however doing a _clean solution_ seemed to fix things — sym3tri, Apr 14 '11 at 06:30
Same problem in VS2013 with ReSharper. I commented the test, problem for future me. — cstick, Jun 12 '14 at 03:52
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. — Tom Bogle, Jul 26 '16 at 14:58
Related post - [Visual Studio 15.8.1 not running MS unit tests](https://stackoverflow.com/q/51967866/465053) — RBT, Apr 27 '21 at 07:31
Does this answer your question? [Visual Studio - suddenly cannot debug tests](https://stackoverflow.com/questions/18024000/visual-studio-suddenly-cannot-debug-tests) — Michael Freidgeim, Jun 03 '21 at 14:01

score 69 · Answer 1 · answered Dec 08 '16 at 14:24

69

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.

answered Dec 08 '16 at 14:24

Helo

1,004
11
15

2

So blooming obvious when you notice that. Thank you! :) – Stu1986C Feb 04 '18 at 20:12
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. – Helo Feb 05 '18 at 23:16
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 – Stu1986C Feb 06 '18 at 07:33

Luis Gouveia · Answer 2 · 2021-03-05T19:45:39.533

18

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

Right click + Debug Test(s) will!

edited Mar 05 '21 at 19:45

answered Feb 23 '21 at 10:00

Luis Gouveia

8,334
9
46
68

1

Thank you! I feel dumb now, I've been chasing this like 20 minutes! – Billy Willoughby Sep 07 '21 at 14:46
@BillyWilloughby, you're welcome, I felt the same – Luis Gouveia Sep 07 '21 at 16:14
1

True that "run tests" not should debug tests but regardless of what I am choosing, the debugger fails to attach. – Anders Lindén Oct 22 '21 at 08:26

score 16 · Answer 3 · answered Feb 14 '18 at 09:31

16

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

System.Diagnostics.Debugger.Launch();

answered Feb 14 '18 at 09:31

huha

4,053
2
29
47

Turns out my test file had other issues. I might write up my own answer... – Super Jade May 03 '23 at 17:08
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. – James John McGuire 'Jahmic' Aug 05 '23 at 12:21
@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. – huha Aug 07 '23 at 05:26
@huha - You may be onto something. It was a while ago, but if I come to this situation again, I will check more carefully. – James John McGuire 'Jahmic' Aug 24 '23 at 16:11

Alexey Potapov · Answer 4 · 2022-07-20T07:30:26.403

16

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

..\Properties\launchSettings.json

edited Jul 20 '22 at 07:30

answered Jul 20 '22 at 07:29

Alexey Potapov

161
1
5

This fixed the issue immediately for me as well! Had a weird WSL launch profile on the test project for some reason. – julealgon Feb 01 '23 at 21:59
This was mine too. No idea where this came from. – Jason Coyne Apr 18 '23 at 22:37
I commented the default profile in this file and it started working – T.S. Apr 25 '23 at 00:40

score 4 · Answer 5 · answered Nov 08 '18 at 11:46

4

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.

answered Nov 08 '18 at 11:46

Andreas Forslöw

2,220
23
32

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. – Casey Crookston Jan 08 '20 at 14:43
Please make sure you also have TestCleanUp or InitializeTest methods public :) – Andreea Purta Dec 05 '22 at 11:14

Peter · Answer 6 · 2021-03-04T08:35:20.633

4

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!

edited Mar 04 '21 at 08:35

answered Mar 04 '21 at 08:13

Peter

971
11
12

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. – Greg Jul 08 '21 at 20:43
Thanks @GregoryBillings - glad it helped you out. Frustrated me at the time:) – Peter Jul 14 '21 at 11:40

score 3 · Answer 7 · answered Jan 21 '19 at 14:16

3

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

answered Jan 21 '19 at 14:16

derekantrican

1,891
3
27
57

That nailed it for me! – Casey Crookston Dec 11 '19 at 19:55

Arthur · Answer 8 · 2018-02-21T07:54:44.283

2

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

edited Feb 21 '18 at 07:54

answered Jan 09 '18 at 20:36

Arthur

2,601
1
22
19

This fixed it for me running VS 2017 v15.5.6 – Dan H Feb 01 '18 at 15:45

score 2 · Answer 9 · answered Dec 29 '20 at 00:22

2

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

answered Dec 29 '20 at 00:22

Gaurav Joshi

861
1
11
17

score 1 · Answer 10 · answered Jun 12 '14 at 03:07

1

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.

answered Jun 12 '14 at 03:07

Frank Socha

147
2
12

1

Did not work for me. – Anders Lindén Oct 22 '21 at 08:25

score 1 · Answer 11 · answered Feb 14 '18 at 09:26

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

score 1 · Answer 12 · answered May 13 '20 at 08:50

1

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

answered May 13 '20 at 08:50

karthik kasubha

392
2
13

Alexandre Paiva · Answer 13 · 2022-10-27T20:11:09.550

1

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.

edited Oct 27 '22 at 20:11

answered Oct 27 '22 at 19:36

Alexandre Paiva

304
3
13

score 0 · Answer 14 · answered Aug 25 '13 at 11:36

0

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

answered Aug 25 '13 at 11:36

score 0 · Answer 15 · answered Jul 26 '19 at 08:39

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

score 0 · Answer 16 · answered May 24 '20 at 12:27

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):

score 0 · Answer 17 · answered Feb 05 '22 at 15:17

0

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

answered Feb 05 '22 at 15:17

roney

964
3
15
37

score 0 · Answer 18 · answered Apr 14 '22 at 11:47

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.

score 0 · Answer 19 · answered Jul 10 '22 at 18:47

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.

score 0 · Answer 20 · answered Aug 17 '22 at 15:14

0

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.

answered Aug 17 '22 at 15:14

Dayo

21
4

Luis · Answer 21 · 2022-09-23T03:42:54.870

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.

Visual Studio "Debug Unit Test" fails to hit breakpoints

21 Answers21

Linked