Debugging unit test cases in VS 2008

Question

Hi all,

I'm trying to debug some of my unit tests in Visual Studio 2008 and have noticed that breakpoints don't seem to be halting execution.

I kind of assumed that it was as simple as setting a breakpoint and then doing "Test | Debug | Tests in current context" ... but this never actually hits the breakpoints that I've set.

Am I doing something wrong or is this just broken?

Thanks, Brandon

Answer 1

Check the following:

• Are the tests marked with [TestClass] and [TestMethod]?
• Are you running Debug or Release mode builds? (Doesn't make a huge difference except when it does) Debug is better.
• Are you compiling with or without optimizations? Without is better
• Try to run All Tests in Solution in check if you hit the breakpoints
• and lastly, maybe you have bug and that's why you are not hitting the code?

Answer 2

I had this same problem until I manually attached to the aspnet_wp.exe process first and then clicked on the Debug Tests buttons. Then my breakpoints were finally hit.

Answer 3

hi

if you use nUnit you have to do following

start Nunit with the DLL you want to test. then in Visual Studio go to Tools -> Attach to Process

choose your nunit process and click "Attach" then it will halt in all your breakpoints

have fun :-)

Answer 4

The official Microsoft workaround/kludge/zomg-I-can't-believe-they-can't-be-arsed-to-provide-this-after-4-years for MSTEST in VS2010, VS2008, and VS2005 is to add System.Diagnostics.Debugger.Break() to the unit test you want to begin debugging from. This works for all projects with debug symbols referenced by the unit test project.

The .NET runtime will prompt you to dump into debug mode (or close the executing unit test program, or ignore the debug line), and (sometimes) allow you to use instance of visual studio that launched the unit test to do so. You can always debug from a new VS instance. Once you hit that System.Diagnostics.Debugger.Break() line, all other breakpoints will be active and hit (assuming they're in the execution stack).