Develop Reference

how to debug specflow test in Visual Studio Code

I have set up an 'nunit' .NET Core project in Visual Studio Code and successfully got my specflow tests running (when I run 'dotnet test' at the terminal).
Now I'd like to be able to debug a test -- but it doesn't stop at my breakpoint in my step file (I have set a breakpoint in my test code, then I click the 'Debug' icon on the left side and then click the Start Debugging button -- but the debugger doesn't stop at my breakpoint).
Does anyone know how to get this working? (Thanks in advance for any thoughts.)

I found a way to debug the specflow test in visual studio code. Go into the cs generated feature e.g. the .feature.cs file.
You have the usual option "Debug All Test" next to the class name.
Like in this picture

In VS2017 breakpoints not hitting sometimes

I'm using VS2017...my breakpoints are not hitting sometimes...when i put a cursor on breakpoint I'm getting an error called "The breakpoint will not currently be hit.No Symbols have been loaded for this document." Can any one help me on this issue.Thanks!!

This happens to me when the code has changed but the build doesn't pick it up. For example, if the code doesn't match the pdb file, then you'll see this.
Clean the build and then build it again, and try again.

Debug.WriteLine skipped while debugging

I am writing a simple C# Code, but the parts where Debug.WriteLine(".."); appear, get skipped. For instance:
WebClient wc = new WebClient();
wc.Encoding = System.Text.Encoding.GetEncoding("ISO-8859-1");
wc.DownloadStringCompleted += new DownloadStringCompletedEventHandler(SearchWordsDownloaded);
Debug.WriteLine("test");
wc.DownloadStringAsync(new Uri("SomeURL"));
Why is that happening?

I was seeing this - Debug.WriteLine() statements being jumped over for a debug build with the debugger attached. Not sure why but the DEBUG compilation symbol was not being set. Go to the project properties page, build section, and within the 'Conditional compilation symbols' field enter 'DEBUG' (without quotes). That caused the debugger to start entering Debug statements again.

The only way it can be skipped is you are running it in release.
Try cleaning the solution, and ensuring it is in debug mode and add a break point in this code segment and press F5.

I've had it skip Debug.Writeline statements if the Active Solution platform is set to either x86 or x64. It seems like they can only be hit if you're Configuration Manager is set to "Any CPU"

This is an old post and I had the problem in Diagnostics using Debug class and Trace class in 64bit console app in Visual Studio 2017. For some who are experiencing this problem in Visual Studio 2017. What I did was to copy the configuration of a console app project properties Build->General setting.

how to debug with xUnit?

I'm learning xUnit and so far, have found it to be a most useful tool. It's making me rethink some of my coding tactics to TDD instead.
However, I've come across an interesting problem. My test case is failing. No real concern there, but how do I debug it?
Specifically my test case is failing due to a "out of index" error, or something similar. It's NOT failing at the assert statement. What I need now, is some way to run the test case with the Visual Studio debugger active so that I can see the status of the different variables.
I'm not going to post code, as this situation is bound to come up again. Does anyone have any idea HOW to debug the test case itself?
Almost forgot! I'm using,
Visual Studio 2010 Ultimate (Dreamspark license)
xUnit 1.9
My workflow involves using the xUnit GUI runner to run the tests.
If what I'm asking is impossible, can someone suggest an alternative test suite I could use that has what I want?

In VS2015 and later, install the xunit.runner.visualstudio NuGet package. Then debugging is as easy as right-clicking on the test in the test explorer window. (Test-->Windows-->TestExplorer if you can't see it). You can also right-click anywhere in the code of the test and Run Test and Debug Test will be in the context menu. If your test is not showing up, be sure the class and method are both public.

I've not tested this but you should be able to attach visual studio to the xUnit GUI and debug from there.
From the Debug menu select 'attach to process', locate the name of the executable in the list and click attach. Set breakpoints in the unit test as required and run the test from the GUI. The breakpoint should be hit as expected.

I have failed in implementing all of the above, but the following worked for me:
Before the lines where you want to debug add the following line (then run the test):
System.Diagnostics.Debugger.Launch();
The drawback is that it will launch another instance of VS :).
Cheers!

In visual studio 2017, make sure that solution configuration is under 'Debug' mode. Under 'Release' mode it is not debugging.

The following will work in VS.NET and in SharpDevelop.
Open the test project's properties and go to Debug tab:
Under "Start Action" set "Start external program" to the xUnit runner
executable of choice.
Under "Start Options" set "Command line arguments" to the name of
your project's debug DLL.
Also set "Working directory" to the project's "bin\Debug\" directory.
Then select Debug > Run or press F5 to run your test in debug mode. Breakpoints will be hit.
The advantage of doing your debugging this way is you don't have to attach to the xUnit GUI each time, you just need to run your test project.

See the answer to this question: Stepping through and debugging code in Unit tests .
Essentially:
...go to 'Test' in the main menu of VS..., click submenu 'Debug' . . .'.
It also works for me using VS2017 ;)

Update for 2020:
If you're using Visual Studio Code with OmniSharp, you can click the "Debug Test" text above the method.

If you have resharper, with X-unit contrib extension installed (seriously recommended!), right click the class in visual studio and click "debug unit tests".
Simple!

set a break point inside of your method.
from visual studio Menu bar, click on Test.
from Debug click on Selected Test or All Test.

I tried all of the above and had no success.
The thing that worked for me is from the following post:
https://github.com/OmniSharp/omnisharp-vscode/issues/1630#issuecomment-317797607
In the .csproj file, under PropertyGroup add the following:
portable

Here's what I did, I just set the breakpoints, and from the menu from the top I choose "Test > Debug All Tests" or "Test > Debug last run"

Enable and disable "Step into" debugging on certain project in a Visual Studio solution

I have a Visual Studio solution with four C# projects in it. I want to step into the code of a supporting project in the solution from my main project, but when I use the "Step into" key, it just skips over the call into that other project. I've set breakpoints in the supporting project, and they're ignored, and I can't for the life of me get it to step into any references to that project.
Everything is set to compile as "Debug", and I've seen Visual Studio warn me that my breakpoints won't be hit before - it doesn't do that in this case. It's as though it looks as though my code will debug, but then at run-time, there's a setting somewhere that tells Visual Studio not to step through the code in that project. All the other projects in my solutions debug without problems.
What box have I checked to cause this behavior?
UPDATE FOR CLARITY: The "Just my code" option is currently disabled. Also, since the code belongs to a project in my same solution, I don't think the "Just my code" option applies here. I thought it only applied to pre-compiled code that I didn't have the source for, but since I have the source in my project, I don't think this option has any effect.

Not sure if this is it, but "Tools>Options>Debugging>General:Enable Just My Code" is a possibility. (I prefer to always leave this unchecked.)

It turns out that the assembly needed to be copied into the GAC before it could be debugged. Under the debugging option "Just my code", there's an option to suppress an error if you don't have any user code, and it was suppressing the following error:
The Following mobile was built either
with optimizations enabled or without
debug information. (Module name and
path) To debug this module, change its
build configuration to Debug mode.
Since I was building it in Debug configuration, I searched on that error message and got this:
http://claytonj.wordpress.com/2008/01/04/the-following-module-was-built-either-with-optimizations-enabled-or-without-debug-information/
Problem solved. I don't know why it needs to be in the GAC in order for me to step into the project, but it does. I don't ask why, I just ask how, and then I do it...

One thing to check for is that your supporting project assembly has not been installed in the GAC. Open a command prompt and run the following to make sure...
gacutil /l assemblyName

You need to ensure the supporting projects have pdb files or else Visual Studio will not have the necessary information to step through the code.

If you have the source code for the dll's into which you are trying to step into, do the following:
Click on the project in which these dll's are added as reference and remove them.
Add the Project(s) corresponding to the dll(s) to the solution
Right click on the project -> Add Reference -> Choose the newly added Project(s).
Now set the break point and debug the code.. You will be able to step into the code.
The reason for the issue is because you program is still referencing the old dll (without the source code) as it has been added to your project as a reference. Once you remove that dll and add the Project (Source code of the dll) of the dll, Visual studio will be able to step into your code.

A couple of possibilities:
There is a check box to step into "just my code". Its intent is to make it so you can't step into Microsoft's Framework code (unless you choose to by unchecking the box).
You might try recompiling the supporting code to make sure the code you're debugging exactly matches the code file you're looking at. VS does care about this and will disable a breakpoint if you put it in the code file whose version doesn't match. Also, make sure the PDB file is in the same directory as the DLL.

In Visual Studio 2013 one way to cause this behaviour is to set build configuration to Release.
Put it back to Debug and see if that helps.