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
I have a Class Library project in Visual Studio and tests for it (everything is written in C#). Once after successful solution build VS shows me this window:
I haven't seen this one before, and I don't know even from what to begin: project compiles without errors and works after compilation, but this window keep appearing after each compilation. When I press Retry or Abort, error message with the same text appears in Output window of VS.
There is only one test method named AddRange1201.
So, the question is - how to get rid of this, besides just checking "Do not show this dialog box again"?
I found this on MS Connect, and I'm not sure if it will fix your problem or not. Sounds like it's a known issue and occurs if you either add the test project to your solution twice (VS doesn't realize it's been added and removed) or if you switch between debug and release modes.
A workaround given is:
1) clean solutions in both modes
2) rebuild in the mode you want
Hopefully this helps.
I want to unit test a user component which use custom events. when doing this without using VS Unit test Framework debug.assert succeed, when doing the same thing with VS Unit Test Framework, assert fails this is illogical so I want to debug while doing Unit test with VS framework. But It seems I can't because code never pause at debug point that I set.
So is there a way to force it to pause at debug point in that case ?
Update: I mean not in the Test Project itself but in the Targeted Project while running the Test Project.
Yes, with the Visual Studio Test project, you can set breakpoints and step through your code.
Be sure to run your tests with the Debug menu -- Tests -> Debug -> Tests in Current Context.
For any given test class or test method, use the keyboard shortcut Ctrl-R Ctrl-T.
When your cursor is in a method (either a test method, or the code covered by the test), it'll break on any breakpoints in that method, or any breakpoints anywhere in the code execution path. If your cursor is on the class, or in between test methods, it'll run all tests in the class. Breakpoints will be hit here as above.
The answer by P. Campbell is not exactly right. If you start debugging a project (such as a WCF services site), it is impossible to start any unit tests, debug mode or not. The options to do so are simply grayed out in Visual Studio 2012.
This means you simply cannot debug out-of-process code from a unit test. You can only debug code that was directly called in process by the unit test.
This is a major problem in VS2012 that they need to fix now.
In VS2015, select:
Test->Debug->All Tests
Or you can highlight a specific test in the editor and select
Test->Debug->Selected Tests
Under the Test Explorer -> Right click on the specific test case you want to debug -> From the Context Menu click Debug the selected test case option.
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.
I've recently been building a test framework for a bit of C# I've been working on. I have NUnit set up and a new project within my workspace to test the component. All works well if I load up my unit tests from Nunit (v2.4), but I've got to the point where it would be really useful to run in debug mode and set some break points.
I've tried the suggestions from several guides which all suggest changing the 'Debug' properties of the test project:
Start external program: C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe
Command line arguments: /assembly: <full-path-to-solution>\TestDSP\bin\Debug\TestDSP.dll
I'm using the console version there, but have tried the calling the GUI as well. Both give me the same error when I try and start debugging:
Cannot start test project 'TestDSP' because the project does not contain any tests.
Is this because I normally load \DSP.nunit into the Nunit GUI and that's where the tests are held?
I'm beginning to think the problem may be that VS wants to run it's own test framework and that's why it's failing to find the NUnit tests?
Edit: To those asking about test fixtures, one of my .cs files in the TestDSP project looks roughly like this:
namespace Some.TestNamespace
{
// Testing framework includes
using NUnit.Framework;
[TestFixture]
public class FirFilterTest
{
[Test]
public void Test01_ConstructorTest()
{
...some tests...
}
}
}
...I'm pretty new to C# and the NUnit test framework so it's entirely possible I've missed some crucial bit of information ;-)
Final Solution: The big problem was the project I'd used. If you pick Other Languages -> Visual C# -> Test -> Test Project ...when you're choosing the project type, Visual Studio will try and use it's own testing framework as far as I can tell. You should pick a normal C# class library project instead and then the instructions in my selected answer will work.
When I need to debug my NUnit tests, I simply attach to the NUnit GUI application nunit-agent.exe using "Debug|Attach to Process" and run the tests from the GUI. Any breakpoints in my tests (or the code they're testing) are hit. Am I misunderstanding your question, or will that work for you?
I use the same technique as you are trying Jon, without the /assembly flag, i.e.
Start External Program: C:\Program Files\NUnit 2.4.8\bin\nunit.exe
Command line arguments: "<path>\bin\Debug\Quotes.Domain.Tests.dll"
Does TestDSP.dll contain all your TestFixtures?
As my test project is not the startup project in the solution, I run my tests by right-clicking on the test project and choosing Debug --> Start New Instance
Simply remove the line that looks like
<ProjectTypeGuids>
{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
</ProjectTypeGuids>
from your project file.
This line basically tells VS.Net that it's a Test project, thus the "Cannot start test project". FYI here the 1st Guid says "it's a test", the 2nd says "it's C#".
For information on those Guids: http://www.mztools.com/Articles/2008/MZ2008017.aspx
In addition to the answer provided by #Justin here are some more details for NUnit 2.6.
Using NUnit 2.6 attach to nunit.exe or nunit-console.exe and NOT the agent. The configuration noted by #Justin is slightly different. Below is an example from nunit.exe.config (same for nunit-console.exe.config).
<startup useLegacyV2RuntimeActivationPolicy="true">
<!-- Comment out the next line to force use of .NET 4.0 -->
<supportedRuntime version="v2.0.50727" />
<supportedRuntime version="v4.0.30319" />
</startup>
For .NET 4 test project, to get break points to hit, you will have to comment out or remove the v2.0 line as the comment suggests. Once I did that I was able to debug the .NET 4.0 test project.
If you are using NUnit 2.4 or newer you can put the following code in your SetUpFixture class. (You can do this with older versions but you will need to do whatever equivalent that has to the SetUpFixture, or copy it in to the test itself.)
[SetUpFixture]
public class SetupFixtureClass
{
[SetUp]
public void StartTesting()
{
System.Diagnostics.Debugger.Launch();
}
}
What Debugger.Launch() does is cause the following dialog to show up when you click Run inside NUnit.
You then choose your running instance of visual studio with your project open (the 2nd one in my screenshot) then the debugger will be attached and any breakpoints or exceptions will show up in Visual Studio.
In Nunit 3.0.1 (I'm using VS2013), Open from main menu > Test > Windows > Test Explorer. Then in "Test explorer", right-click the test case, you might see:
Hope this helps.
Install TestDriven.NET, which is a plugin for Visual Studio
From there you can right click on your unit test assembly and click Run Tests to run the whole suite, right click on a TestFixture class to run just the tests in that class, or right click on a Test method to run just that method.
You also have the option to Test With Debugger, if you need to breakpoint into your tests in debug mode.
Try NUnitit - a open source Visual Studio Addin for Debugging NUnit Test cases
HomePage - http://nunitit.codeplex.com/
Remove ProjectTypeGuids from the project file.
Now with pictures:
Run NUnit gui (Download 2.6.2 from here) then go to File -> Open Project
Select your test .dll from bin folder (C:\......\[SolutionFolder][ProjectFolder]\bin\Debug\xxxxTests.dll)
Go to Visual Studio Debug -> Attach to process (Attach to process window will open)
From the list scroll down and select nunit-agent.exe then click Attach
At this point breakpoints in your tests should turn ripe red (from hollow).
Click Run on Nunit Gui and you should get your breakpoint hit...
Hope this saves you some time.
If you are able to get the console / or GUI working, but your breakpoints are not being hit, it may be because your app is running a different .NET runtime than NUnit is. Check to see if your nunit-console.exe.config / nunit.exe.config has the runtime specified.(The configurations live in the same directory as the nunit exe's.) Specify the runtime using the startup node:
<configuration>
<startup>
<supportedRuntime version="4.0" />
</startup>
If project path contains spaces e.g. "New Project" in path <path>\bin\Debug\New Project\Quotes.Domain.Tests.dll then enclose the Start Option --> Command Line Arguments project path in double quotes.
I spent a lot of time to figure this out.
Regarding what Mr. Patrick McDonald said
As my test project is not the startup project in the solution, I run my tests by right-clicking on the test project and choosing Debug --> Start New Instance
I tried to apply for my test class library but got some error regarding the path, so I tried to remove the 'Command Line Arguments', and luckily it worked well and as expected.
It sounds like you are trying to use the wrong library. NUnit can only start if the dll you are using contains TestFixtures.
+1 on TestDriven.Net. I've had the chance to use it a number of times.
You can download the personal version for evaluations purposes according the the license at http://testdriven.net/purchase_licenses.aspx.
I got the same error with MSTest. I found that in the Test Output window, some of the tests had duplicate IDs and could not be loaded. I removed all duplicate tests and now I was able to run the tests when i start the project.
There is also an extension now "Visual NUnit" that will allow you to run the tests from within Visual studio much like the build in test framework handles. Check it out its in the extension manager.
Open Visual Studio ---> your Project---> Select 'Properties'---> Select 'Debug' --> Select 'Start external program' and set the path of your NUnit there(Eg: Start external program = C:\Program Files\NUnit 2.6.2\bin\nunit.exe) ---->Save
After setting this just click Debug
For me solution was to adapt nunit configuration file. To use nunit with 4.5-.Net framework and x64 build option, I had to add one line to startup tag (supported runtime-version).
<startup useLegacyV2RuntimeActivationPolicy="true">
<!-- Comment out the next line to force use of .NET 4.0 -->
<supportedRuntime version="v4.0.30319" />
</startup>
Afterwards, I could start by right-click on the Testproject Debug -> Start new instance.
Before, I needed to again manually attach the project to the process.
My Debug properties were,
C:\Program Files (x86)\NUnit 2.6.4\bin\nunit.exe
with argument of the location of the .dll to be tested.
More information: nunit for testing with .NET 4.0
See if this helps..
How to add NUnit in Visual Studio
(RighteousRant)Although personally I don't like this approach.. If you need a debugger while you are test-driving your code, it's a "smell" in that you do not have enough confidence/know how your code works & need the debugger to tell you that. TDD should free you from needing a debugger if done right. Use 'Attach debugger to NUNit' only for rare cases or when you are wading in someone else's code.