CODEWITHSUNDEEP
.netvisual-studiodebuggingvisual-studio-2008resharper
sym3tri
sym3tri

Reputation: 3823

Visual Studio "Debug Unit Test" fails to hit breakpoints

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.

Upvotes: 63

Views: 56055

Answers (25)

live-love
live-love

Reputation: 52366

Build your tests.

enter image description here

Make sure you don't run your main application, otherwise you will get this when you run your tests (breakpoints will not be hit):

enter image description here

Debug your tests.

Upvotes: 0

Omar Barakat
Omar Barakat

Reputation: 1

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

Upvotes: 0

Mark Nash
Mark Nash

Reputation: 192

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.

Upvotes: 0

Ash K
Ash K

Reputation: 3631

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;
}

Upvotes: 0

Alexandre Paiva
Alexandre Paiva

Reputation: 304

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.

Upvotes: 1

Luis
Luis

Reputation: 1235

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.

Upvotes: 0

Dayo
Dayo

Reputation: 61

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

enter image description here

Version 17.2.3 didn't work.

Version 17.3.1 works.

Upvotes: 0

Alexey Potapov
Alexey Potapov

Reputation: 381

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

..\Properties\launchSettings.json

Upvotes: 28

Shimmy Weitzhandler
Shimmy Weitzhandler

Reputation: 104692

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.

Upvotes: 0

XzajoX
XzajoX

Reputation: 23

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.

Upvotes: 0

roney
roney

Reputation: 1082

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 enter image description here

Upvotes: 0

Luis Gouveia
Luis Gouveia

Reputation: 8925

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

Right click + Debug Test(s) will!

Upvotes: 20

Peter
Peter

Reputation: 1121

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!

Upvotes: 4

Gaurav Joshi
Gaurav Joshi

Reputation: 1001

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

Upvotes: 2

Shahar Shokrani
Shahar Shokrani

Reputation: 8740

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

enter image description here

Upvotes: 0

karthik kasubha
karthik kasubha

Reputation: 424

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

Upvotes: 1

Mike
Mike

Reputation: 937

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

Upvotes: 0

derekantrican
derekantrican

Reputation: 2275

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

Upvotes: 3

Andreas Forsl&#246;w
Andreas Forsl&#246;w

Reputation: 2738

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.

Upvotes: 4

Arthur
Arthur

Reputation: 2639

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

Upvotes: 2

huha
huha

Reputation: 4245

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

System.Diagnostics.Debugger.Launch();

Upvotes: 19

huha
huha

Reputation: 4245

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

Upvotes: 2

Helo
Helo

Reputation: 1054

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.

Upvotes: 74

Frank Socha
Frank Socha

Reputation: 157

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.

Upvotes: 1

user1400995
user1400995

Reputation:

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

Upvotes: 0

Related Questions