CODEWITHSUNDEEP
visual-studio-2008unit-testingdebugging
My Other Me
My Other Me

Reputation: 5117

Visual Studio Debugger skips over breakpoints

My Visual Studio 2008 IDE is behaving in a very bizarre fashion while debugging a unit test: I have a breakpoint and when I hit it and then try to step with F10 the test concludes. If I Set breakpoints on every line inside the method being tested I will end up at a random one, not the next one on the following line. I have cleaned and rebuilt the solution after a clean system restart. The behavior persists. Has anyone else experienced this and come to a conclusion.

This test only used the main execution thread (no additional threads are being created)

Upvotes: 15

Views: 13171

Answers (13)

ΩmegaMan
ΩmegaMan

Reputation: 31576

My unit tests were testing under x86. Changing them to x64 worked.

Menu

Test -> Test Settings -> Default Processor Architecture -> x64.

Upvotes: 0

Jeff
Jeff

Reputation: 77

I just encountered the same issues and went through all the suggestions above with no luck. Come to find out at some point in the past someone had changed the method signature to be "private" when it must be "static" or "public". As soon as I changed the test method's signature back to "public", the break points started working again.

Upvotes: -1

Ben Osborne
Ben Osborne

Reputation: 1542

I ran into this in Visual Studio Community 2013. The behavior appears to be by design. When running tests, execution will not stop on breakpoints. When you want execution to stop on breakpoints, selects TEST --> Debug rather than TEST --> Run.

Upvotes: 0

Hans Passant
Hans Passant

Reputation: 941217

There was a post VS2008 SP1 hotfix released that solves a number of debugging problems. The KB article is here, the hotfix download is here.

UPDATE: the hotfix download location was retired, I don't know of an alternative download location. Please edit this post if you find one.

Upvotes: 27

Rohit.Net
Rohit.Net

Reputation: 33

May be it is too late to reply, I got same issue in VS2012 to fix that please check if menu Test>TestSettings> "LocalTestRun.TestRunConfig" is checked, if it is checked uncheck it and it will stop skipping the code lines. May be same for Vs2008 also work.

Upvotes: 0

Patrick
Patrick

Reputation: 1

Go into Project->Properties and uncheck "Optimize Code"

This is the case if you see code such as DataSet ds = new DataSet(); gets hit on the debugger but code like string Test = "Test"; gets skipped.

Upvotes: 0

Jacob
Jacob

Reputation: 78850

This may be as simple as a case of the testing framework not loading the same assembly that you're currently working on. I've had this happen in rare cases in NUnit, which works off a copy of your assembly under test; occasionally, it stopped copying over the most recent version. Are your breakpoints decorated with a "symbols have not been loaded" indicator?

Upvotes: 0

Mike Schenk
Mike Schenk

Reputation: 1582

Are you putting your breakpoints inside code that is part of a generated class?

I have experienced this problem on the client site of a service reference. The generated classes are partial classes with the

    [System.Diagnostics.DebuggerStepThroughAttribute()]

attribute applied. Even when my breakpoint was in a different file, but still part of the attributed class, the breakpoint would be skipped.

I removed that attribute from the generated Reference.cs file and the debugger worked as I expected.

Of course, this isn't a permanent solution because if the Reference.cs file gets regenerated, the attribute comes back.

Upvotes: 2

Michael Baldry
Michael Baldry

Reputation: 792

This behaviour also happens when you have multiple threads running.

Upvotes: 3

Arlen Beiler
Arlen Beiler

Reputation: 15866

F10 is Step Over, F5 is continue to next breakpoint, F11 is Step Into, which executes the next line of code then waits. That is what you are probably looking for.

Upvotes: -1

jeroenh
jeroenh

Reputation: 26772

Even in a Debug build, compiler optimizations could explain this behaviour. Under project properties, "Build", verify that the checkbox 'optimize code' is turned off. I have seen this turned on by default after upgrading certain projects from .Net 1.1.

Upvotes: 2

sinek
sinek

Reputation: 2488

I had similar issues on VS 2003. It turned out that I was using wrong symbols so they could not be bind to correct source.

Make sure in a following:

  1. That you're using the Debug build (or that any kind of Optimization is turned off)
  2. That build output path is OK ( that "Project Properties\Linker\Output File" match to the exe you're debugging)
  3. That you don't place breakpoints on variable declarations: i.e. if you place a break point on "int some_variable;", you will never hit it but instead you'll hit the first place after it where you defining\initialize something or calling some methods
  4. You can't step-into with F10 (executes next statement) but with F11 (executes next statement and follows execution into method calls)
  5. Make sure you don't have any filters on breakpoints (i.e. Hit count or condition)

p.s. try placing the DebugBreak(); function in both methods (unless this code is executed inside some loop so this might be frustrating). This should cause terminating your process when execution reach any of these functions (so you can continue with debugging from that particular place).

Upvotes: 4

Toad
Toad

Reputation: 15925

This behaviour happens if you debug the release build (since lines are optimized away).

It also happened to me in the past if by accident I'm debugging an older exe somewhere else (as set by the project config), instead of the most recently build one ;^)

Upvotes: 11

Related Questions