I'm cheap and don't want to pay for ReSharper or TestDriven.NET, is there a free visual Studio addin for NUnit?
You can create a blank project (Choose console application for example) and in the property of the project you can select DEBUG tag and select "Start External Program". Put the path of Nunit. Then, in the start option, the command line arguments select the DLL that contains all your tests (mine is always in the nunit\bin...). Then select "enable unmanaged code debugging" and you will be able to start the project inside VS and even use the debugger step-by-step.
This is a free solution.
Now you can use Gallio: it's open source. www.gallio.org
By the way TestDriven can be downloaded for free if it's for personal use or Open Source project.
I had to find a way to use .Net Reflector inside VS few days ago and when I downloaded TestDriven it cames with. Never got any popup asking me to paid.
NUnit actually ships with a basic integrated runner. It's not very good, and not very publicized, but unless Charlie has taken it out, it should be in the source.
I know this is an old question but another way to do this is to add an external tool from the tools menu to run nunit - set the arguments to be $(TargetName)$(TargetExt) and initial directory to $(ProjectDir)\bin\Debug
check out this link
This is an old question and things have changed since the answer was accepted.
You may try NCrunch to run tests automatically or manually.
If you're running Visual Studio 2012, there is a plugin written by Charlie Poole, one of the NUnit contributers, that makes use of the new Visual Studio Unit testing plugins.
Download VsTestAdapater - it's also in the extension manager.
Unfortunately it doesn't have much grouping options yet, either by run/not run - so you can't group by class, solution and so on. It also doesn't show you any stacktrace if a test fails, just a simple green tick or red box and a message.
I haven't used it, but NUnitit is a free Visual Studio Add-in for NUnit.
http://nunitit.codeplex.com
From my experience, the best add-in for visual studio is resharper. TestDriven.Net is also good for unit tests. Hope that helps
Also found this one : http://visualstudiogallery.msdn.microsoft.com/c8164c71-0836-4471-80ce-633383031099
It is able to launch your tests in debugger, however you need to recompile the code manually each time you change something - no auto run-build integration
Related
I am working on an SSIS package. The package has a script (C# language) task. I need to debug the script task. I set the break point. The script in script editor (Visual Studio) and the task in SSIS package editor, both, show break point in red color - means the break point is enabled. However, when I debug the package the break point does not hit.
The break point has no conditions on it, so I expect it to hit every time the package runs.
I am using Visual Studio 2008 on Windows 2003 R2 64-bit SP2.
After more research and trial-error, found that the SSIS package ignores the breakpoints in a Script Task when debugging on a 64-bit machine. To fix it -
Go to the Solution Explorer
Right click your SSIS project node > Properties
In Configuration Properties > Debugging > Debug Options > Set Run64BitRunTime to False.
After making this change, the breakpoints hit like magic.
I tried all the answers provided here with no success (using VS2015). After some more searching I found this question that is actually an answer which stated that newer C# features / syntax were causing the debugger to not fire correctly.
In their example (and also mine) using string interpolation was causing the breakpoints to not be hit.
Replacing
$"{someVariable} - {someOtherVariable}"
with
string.Format("{0} - {1}", someVariable, someOtherVariable);
did the trick for me.
EDIT
It appears this issue has now been fixed with SQL Server Integration Services Projects, but you need to be running VS2019 to download it.
Update: Guys, I againg lost any ability to set breakpoints (a request to MS)
My previous fixes are below.
Now I'm using logging and tracing instead of debugging.
C# new features (after C# 4.0) are blamed for killing debugging of the SSIS Script Task.
To return the breakpoint capability I do the following.
Remove C# new features
Run my Script Task once, successfully. I.e. without a crash.
Reopen the Vsta Project from my Script Task and put breakpoints there.
At the end, you have to see a red circle on your Script Task.
(Tested in VS 2017.)
Note. I have to mention that debugging works even if your use "Execute Task" only, not "Execute Package"!
Remove C# new features
To remove the C# new features, I can advise you two ways.
First, restrict Vsta Project properties to C# 4.0 (migrated packages may not support this).
Dobule click your "Script Task" to open "Script Task Editor".
Click "Edit Script..." button to open Visual Studio.
In "Solution Explorer" select the project and click the F4 key on your keyboard.
In opened "Properties" window in "C# Language Level" choise "C# 4.0"
Build your project and fix compilation errors.
Secondly, Vsta Projects in old/migrated packages may not show the above "C# Language Level" property.
So you can put your code in a fake project in Visual Studio 2010 and compile it there.
Run it once successfully
After you fix your C#, you have to run your Script Task once successfully.
You may want to put the return statement at the beginning of the Main() method to prevent any real execution.
Sorry, this doesn't always work and I don't realise why but you definitely need to fix your C# in the first place.
At least you will get a working Script Task and can debug it in an old fashioned way (logs by Dts.Events..., exceptions, etc.)
TL;DR
It looks like I even got severe cases when C# new features forced Script Tasks to fail silently with a success completion status.
As an example, add the following to your Script task.
string Bug { get; } // Only getter properties.
//...
var str = $"Now is {DateTime.Now}"; // String Interpolation in C#
//...
var dummy = val?.ToUpper(); // ?. and ?[] null-conditional Operators
And workarounds for this non-complete list:
string Bug { get; set; }
//...
var str = string.Format("Now is {0}", DateTime.Now);
// etc.
What I also do, I build my C# code in Visual Studio 2010. It simply doesn't compile the new .NET features and do not allows .NET Framework versions above 4.0. So far, so good.
Of course, other answers from this SO-question didn't help me.
In my case, none of these solutions worked. I finally got to know that the Resharper was culprit. After uninstalling it, it started working like charm.
In my case, I had to get rid of all features from C# 6: string interpolation, null conditional operators (?., ?(), ?[]) and expression-bodied members (=>) (there might be more in your case). You can check them all here. Of course, the same applies to C# 7 features.
The 32/64 bit changes from other answers didn't help, so I rolled back those and the debugging kept working just fine.
Use System.Diagnostics.Debugger class to add breakpoint programmatically:
System.Diagnostics.Debugger.Launch();
System.Diagnostics.Debugger.Break();
You can check if the debugger is attached or not:
if (System.Diagnostics.Debugger.IsAttached)
System.Diagnostics.Debugger.Break();
Follow these step:
Keep your project or solution opened.
Run your app to hit breakpoint.
Select your project in Just-In-Time Debugger.
I inherited an SSIS package where unfortunately the above answers didn't help.
In the end I found the script task's build properties for debug mode had had the optimize code ticked. Make sure this isn't ticked because for me visual studio would fire up for script debugging and close shortly after without breaking at all.
Pretty obscure but worth a mention.
We hit the same problem recently. For us the solution was to ensure that the script task project was marked to run as with the platform target set to x86.
Edit the script task
Click on the project and select properties
Select to set the platform target to x86
In addition to Jeff's suggestion, also change the Platform Target to "x86" (In the script's properties' Build tab. This FINALLY got me debugging again on a 64-bit system.
Microsoft released an update v3.2 of SQL Server Integration Services Projects where it resolves the issue with Roslyn and other C# language features introduced after .Net 4.5. C# features.
Bad news - this fix is for Visual Studio 2019 only, you have to upgrade your VS to use it.
I spent whole day on this and NONE of the solutions mentioned here worked for me.
In my case, the existing project was targeted to SQL Server 2016 which defaults ScriptLanguage Microsoft Visual c# 2015. This doesn't allow debugging in VS 2019. I have to target project to SQL Server 2019 to make debugging work. Of course, I am not going to checkin version change. It's only to debug script. Once script is working, I am going to revert target version to SQL server 2016.
Hope this saves time for someone.
I had the same problem as you #PAS. Using VS 2019 and Target server version 2016.
Just found out that if upgrading SSIS in Visual Studio (going into Extensions->Manage Extensions) to latest version (which now is 3.15) debugging is now working.
My breakpoints refused to hit no matter what I did. I ended up debugging and fixing the issues just using exception throws. Once I had fixed the issues I was having, the breakpoints started hitting!
So my breakpoints would only hit once the code did not experience any runtime issues... which is bizarre.
In my experience, it doesn't matter:
if Run64BitRuntime is true or false
if you build the 32 or 64 bits version of your package
But there is something very important, not mentioned in any other answer: you must run the whole package. If you run a Task or a Container the breakpoint will be ignored.
I'm using Visual Studio 2013, on a 64 bits machine.
I only had one Script component were no breakpoints were hit (I was doing some CRM stuff without needing source/target).
I trid to add a Source componenet with a simple fetchXML (even if I didn't needed it).
Then it worked! :-)
I found out that by copying a Script Component task, the VSTA project as a whole is copied as well. This is what you would expect, but what I did not expect is with that, the assembly name for example is also copied.
Running then Execute Task works fine, but running the whole package actually only runs the first script that was copied and resulted in exceptions being thrown before ever hitting the row processing function.
That was also the reason for me that breakpoints were not being hit.
I have a huge visual studio 2013 solution in c++, containing three types of projects : one console project that handles google tests, dll projects, and a static library project for the google test static libraries.
Often when I code and run the all the google tests, some tests happen to fail, and I have to debug them. To do this, I have to run the google test executable with a special option telling just to run the special test I want to debug etc...
After some time, it starts to be boring. That's why I have the following idea : I would like to have, when right-clicking in the middle of a test case, one more line at the end of the window appearing in visual studio 2013 (when I right-click) called for instance "debug this test" that would trigger the debug of this test.
I really didn't know the technology adequate to do this, but digging a bit brought me in the "visual studio 2013 add-ins" field, which is the right technology to achieve want I'd like to do. (To have when right-clicking in the middle of a test case in the c++ code, one more line at the end of the window appearing in visual studio 2013 (when I right-click) called for instance "debug this test" that would trigger the debug of this test.)
Is there any "examples" somewhere that I could inspire myself of ? Or could anyone guide me on the subject ?
Sorry I can't help VS2013 unfortunately. My professional career skipped that one.
However Visual Studio 2015 does give this functionality out of the box.
I'm sure there are some tools that can do this in VS2013, but I don't think its default?
https://msdn.microsoft.com/en-us/library/hh270865.aspx
EDIT. Apparently it is there is VS2013 and VS2012?
Has anyone integrated NUnit with Visual Studio? I'm trying to set up a build pipeline like this one. But, I'm pretty new to .NET and I'm still understanding how things work. There are many resources in the internet on NUnit + VS, and I'm confused.
I'd recommend you to use Resharper.
As some say, "It just works".
Disadvantages/side effects of this choice in your case could be:
1. Resharper is not free;
2. Running unit-tests is minor part of Resharper - it also includes tons of other features, which you maybe do not need for now(but you can disable most of them in setttings).
Free solution is - Visual Nunit 2010 Visual studio extension. Free and does exactly what you want.
UPDATE
How to add NUnit to your project.
I've found this tutorial. Follow it step-by-step, I've found it helpful and complete for .NET novices.
The only difference is that in Running Unit-Tests section for running tests author uses test runner tool that is distributed within NUnit itself, but you can use ReSharper runner as described in JetBrains' docs
I'm using this:
http://visualstudiogallery.msdn.microsoft.com/c8164c71-0836-4471-80ce-633383031099
Which works quite well for me. You can access it within VS2010 from View->Other Windows->Visual NUnit
I used TestDriven until it was no longer free, I used Resharper but felt it slowed down my machine too much, I tried the VisualNUnit extension but it appeared to spawn multiple processes of itself that would keep a hold on some of my DLLs, I added NUnit itself as a command under Visual Studio Tools (and also with a toolbar button and some macros in Visual Studio to start the current test and attach) but that cost some effort to set up and didn't feel smooth enough after being spoiled with tools like TestDriven. Eventually I tried NCrunch... I am hooked ever since, and I have even started to favor it over TestDriven! the next tool on my "NUnit bucket list" will be the NUnit extension for Visual Studio 11.
PS: NCrunch should work on your Visual Studio 2010 and the homepage has a very decent demo video.
First download and install the NUnit
Step 1: Open Visual studio
Step 2: Open your project
Step 3: Select Properties from Solution Explorer
Step 4: Select Debug option in the properties window
step 5: select 'Start external program' under the section 'Start Action'
Step 6: Select the path of the NUnit file
Step 7: Save it.
After that when you debug your project NUnit will open.
Setting up Visual C#2010 Express with NUnit
The original and still quite ok test runner.
Test Driven .net
Used to be free, but now costs a small fee unless you're a student or open source developer.
Visual Studio 2011(BETA) is compatible with 2010 and provides test runners out of the box. Refer to Visual Studio 11 Beta Unit Testing – What’s New and Visual Studio 11 Beta - Unit Testing Plugins List. For continuous integration (CI) server U can use TeamCity and also run those test on the server.
I have written a NUnit test in Visual Web Developer 2008 Express. But when I run the test, it doesn't pause at the breakpoint I had set. It just keeps on running but at the breakpoint, I need a step-by-step view on the test.
Could anyone please tell me how I can use breakpoints with NUnit?
Thanks in advance!
This is how you do it... - http://codebetter.com/blogs/paul.laudeman/archive/2004/03/18/NUnit-Tip_3A00_-Debugging-your-unit-tests.aspx
However I'm not sure if Express editions of VS support 'start external program' for debugging / 'attaching to a process'. In which case, you may need to upgrade to be able to debug.
This is easily done with VS C# Express - have a look at:
http://www.dotnet-developer.de/2009/10/aspnet2005/how-to-use-nunit-with-visual-studio-express-2008/
However I don't know if this will apply to Web Developer.
I assume you are running NUnit from outside Visual Studio, since the Express versions do not support Plugins. I don't think you can debug NUnit tests that way. If you had a non-Express version you could use the testdriven.net-plugin for debugging. Maybe if you set the NUnit runner as program to execute on debugging with you assembly as command line parameter...
I want to start using Nunit (finally), I am using Visual Studio 2008.
Is it as simple as importing Nunit into my test project?
I remember seeing a GUI for NUnit, does that do the exact same thing that a separate test project would do, except show you the pass/fail visually?
I like to add a link to NUnit in my external tools.
Under Tools->External Tools add NUnit
Title: &NUnit
Command: <path to nunit>
Arguments $(ProjectFileName) /run
Initial directory: $(ProjectDir)
After that you can quickly run it by compiling then hitting alt-t + n
Yes, that's basically it. Personally I find the unit test runner which comes with ReSharper to be excellent - and the tool itself is well worth the licence feel. Alternatively there's TestDriven.NET.
Having a test project which runs nunit-gui or nunit-console separately is all very well, but you really want the whole unit testing experience to be as seamless as possible. The easier it is to write and run tests, the more likely you are to do it - which is a very good thing. Don't underestimate the gradual build-up of frustration due to a slightly poorer user experience, flipping between windows etc.
NUnit is something that isn't inside Visual Studio 2008. It does have a console OR a graphical user interface (gui) that can be run both outside VS2008 OR can be attached to the process of VS2008 for debugging.
If you do want something inside VS2008 you need to have a third party pluging like ReSharper.
Edit: This has been answered in the past (not for VS2008 specificly but still relevant)
I've used TestDriven.NET with VS2005, and it has changed how I develop and test code.
You can run all of the tests on any class, module, project, or solution. You can also run a test in the debugger, which is tremendously useful to diagnose and fix issues when they crop up.
The GUI is nice, but if you run your tests often, you'll probably abandon it for a faster/integrated runner.
In any case, you have some options on how to run your tests:
NUnit.Gui.Exe -- you can run this & select your test project dll to run the tests. While it is open it will refresh when you build, so you can ALT-TAB to it & re-run your tets. Another technique I've seen is to set this application as the startup program for your test project. Then set your test project as the startup project and push F5.
Download & use TestDriven.net. This is fast and lets you run tests from a right click menu, while you're sitting on a test or at a node in the solution explorer. This is what I use mostly. I have it mapped to CTRL+T for quick access.
Resharper has a test runner as well. This gives you the GUI with red/green lights inside of visual studio. It also gives you a little icon next to each of your tests to quickly run them.
You can use the plugin NUnitForVS that is available here: http://www.codeplex.com/NUnitForVS
This integrates the test running and results in your VS 2008 IDE. We've been using it for a couple of months and it's working well for us.
You should also remember that with VS 2008 professional you can use the MS Unit testing tool that was previously only available in the team versions.
You can run it as external program, but as for me it is not very nice. I like, when test starts within the VS. So, if you have ReSharpe you can go to Tools -> Options -> Environment -> Keyboard and set the hot key for ReSharper_UnitTest_ContextRun. I set it to Ctrl + t.
I attach my nunit console program to the Post-build event so every time I build my project the tests are run without the need for third party tools (apart from NUnit). I'm using Visual Studio 2010, but I am pretty sure you can achieve the same behaviour in Visual Studio 2008.
To do this:
Open the project's properties window (the project containing the tests)
In the Post-build event command line add the line:
"C:\Program Files (x86)\NUnit 2.5.10\bin\net-2.0\nunit-console-x86.exe" "$(TargetDir)$(TargetFileName)"
Build the project and the output should be written to the Ouptput window (Build). It's important to choose the x86 version of the console runner.