Related
I am getting the following error message when trying to run unit tests in Visual Studio:
NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll
I am using
Visual Studio Community 2013
NUnit Adapter 3.4.0.0
NUnit 3.4.1
The weird thing is, that I have another project which is set up the same way as this one and it works just fine.
I also downloaded NUnit 3.4.1 and installed it. When I run
nunit3-console.exe Trading.Tools.Test.dll
everything works just fine.
Any ideas what I can do?
Many thanks
Konstantin
Edit #1
Here is the full console output from Visual Studio when trying to run all test.
Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run:
Trading.Tools.Test.dll, Trading.Tools.dll are built for Framework Framework45 and Platform X64.
Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings.
NUnit Adapter 3.4.0.0: Test discovery starting
NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll
Assembly contains no NUnit 3.0 tests: w:\Repos\trading.tools\Trading.Tools\bin\x64\Debug\Trading.Tools.dll
NUnit Adapter 3.4.0.0: Test discovery complete
As you can see it is very obvious that NUnit expects a x86 build, but I build for a x64 platform. And again, my x64 build works just fine if I execute it using nunit3-console.exe.
What I see in the csproj file is this:
<Reference Include="nunit.framework, Version=2.6.4.14350, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\NUnit.3.4.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
The weird thing here is that it specifies using Version=2.6.4.14350 but referencing a 3.4.1 dll.
So the next question from this point is how can I make NUnit execute my x64 build? Any ideas?
I had a similar issue, the key is the fact that it is the Test Runner in Visual Studio that is stating that only x86 assemblies will be tested. I am assuming from this that it then forces the use of the x86 NUnit runner. To change this (in VS2015 and VS2017 at least), go to Test > Test Settings > Default Processor Architecture > X64.
You can also set the execution target in the runsettings file. You then have to select that file. This should make the solution more stable.
A runsettings file which only set this can look like:
To enable it, do as shown in the figure below:
When you select it from the test menu (1), it will be added as the selected one in the menu (2), and a Rebuild will then make the test appear in the Test Explorer (3)
There is an extra bonus by using a runsettings file, and that is that it will then run properly on the TFS Build system, if you use that. I have written a blog post on that issue, see http://hermit.no/how-to-control-the-selection-of-test-runner-in-tfsvsts-making-it-work-with-x86x64-selected-targets/
I couldn't execute my tests and found that to be one of the issues. It turns out that my TestFixture was internal. Just switching it to public solved my case.
After unsuccessfully trying all other responses above, the following worked for me:
In my case the .NET project and solution is on a mounted drive (I use a MacBook and Parallels for .NET development). The mount also contains the /bin/debug and /bin/release locations where NUnit was attempting to read the "test" DLL from.
The fix was to move the solution/project files to the C: drive of my Windows image. The tests were discovered immediately.
Apparently the shared/mounted location was not to its liking. I don't know why, since the mount is permanent and read/writable to all users on the Windows image. I suspect file permissions problems or maybe somehow the entire mount is not accessible to the user/process running the NUnit discovery logic.
I happened to get this error when writing the unit test method. And noticed the root cause that one of the dependent dll was missing to load. This error("NUnit failed to load the .dll") was shown in the Output("Test") window after modifying the test method code and trying to run it. After updating the nuget package for the dependent dll, nunit started picking the test project dll and test cases got executed.
Today I was running into this issue as well (on a .NET Framework 4.8 based NUnit project). The solution for me was to also install the Microsoft.NET.Test.Sdk package.
To get to the root cause, it may help to attempt to run your tests using the NUnit CLI.
In my case, the CLI logged a bind failure I didn't see in Visual Studio. After I had fixed that, my tests ran correctly via CLI and VS.
I got this error in a .Net 6.0 Asp.Net solution and here's how I solved it.
It was only occurring in one Test project whose tests wouldn't run, the other Test projects were running fine in Test Explorer and in Debug.
The tests that were failing to be detected had "Test Not Run":
In the Output is the error:
NUnit Adapter 4.3.1.0: Test discovery starting NUnit failed to load [dll path]
No test is available in [dll path]
What I did was comment out each class and bring them back one by one until the Tests would STOP to RUN. Then with the failing class put a break point on a [Test] method.
If you can't hit the break point then its failing in this classes [SetUp]. Put a BreakPoint in the [SetUp] and use F11 to step off the edge of the method, ie F11 off the final curly brace..
AND THEN you get a prompt saying which DLL it can't load.
In my case it was “couldn’t load a DLL Microsoft.AspNetCore.Mvc.Core”
Referencing the DLL via Package Manager resolved the problem.
Edit: if this happens in a Unit Test you may want to reference the Microsoft.AspNetCore.App FrameworkReference rather than the Microsoft.AspNetCore.Mvc.Core package reference:
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
We have an ASP.NET MVC 4.5 project. For months it has been compiling and all unit tests passing locally on our development machines and on the TeamCity 7.1.5 machine. Monday we updated to newer versions of some of our dependencies (specifically, to get OData 5.0.0-rc1 for select-expand).
The project compiles fine on our development machines and the build machine. It runs fine on our development machines and on both QA environments it's deployed to. All the unit tests pass on our development machines. However, about half (~300) of the unit tests now fail when run from TeamCity using the MSTest build runner, all with the same, useless error:
Unit Test Adapter threw exception:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
I've tried everything imaginable. At first I figured there was a legitimate problem. Since there's no way to retrieve the LoaderExceptions property from TeamCity (why doesn't MSTest just display more information!?!?), I logged in to the machine TeamCity is running on, opened up the console, changed into the work directory that our build is running from, and ran the tests manually so that I could retrieve the property. ALL OF THE TESTS PASSED! There goes that theory...
After an entire day of Googling and reading other answers on StackOverflow, I've tried about two dozen different combinations of the following steps:
Changing the build from "Rebuild" to "Clean," running it without tests so that it just cleans, changing it back, and running it again.
Changing the build from "Debug" to "Release," running it, and changing it back again.
Cleaning agent sources from TeamCity admin pages.
Manually deleting entire work directory off of the agents, skipping the recycle bin and going straight to the netherworlds.
Deleting all source control (TFS) caches off the build machine and agents.
Telling TeamCity to clean the work directory before getting latest from source control.
I've reached the end of my troubleshooting capabilities. The tests just won't run anymore on the build machine, for apparently no reason at all.
What can I do? What the heck is going on?
The short answer to this is, "It's a bug."
I reported the bug to JetBrains. It appears that, though there might be some underlying problem with my project, it's only a problem when run from Teamcity, and it's impossible to retrieve the actual error message, so there's no way to know what that problem is. The runner should be catching the exception and printing out the LoaderExceptions property, but it isn't. Instead, it's just calling ToString() on the exception. The runner will have to be updated to look for this specific exception and print the LoaderExceptions property. Once that happens, then we can see the underlying problem, which may result in changing something in the project, or it may result in filing another bug with JetBrains.
Workaround
I spent quite some time debugging our Continuous Integration build failure while experiencing this bug. Since Jetbrains doesn't address the issue, I thought I'd post my workaround here so others have something to work with.
My problem was that the build failed on the step which runs the unit tests. Coincidentally the build which failed added a unit test project. When the newly added unit tests were excluded, everything ran successfully. Because of the reasons stated above and Teamcity not handling the exception properly, debugging options are limited.
I never found a solution which doesn't get your hands dirty, but what you can do is the following. It's basically manually running MSTest versus the test assemblies on the build agent and does require remote desktop access to it. In my case, Teamcity ran the unit tests from the following directory:
C:\BuildAgent\temp\buildTmp[NAME TIMESTAMP]\Out.
Run the following command to initiate the MSTest runner on the assembly which contains failed tests:
C:\BuildAgent\temp\buildTmp\Out>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe" /testcontainer:"C:\BuildAgent\temp\buildTmp[NAME TIMESTAMP]\Assembly.With.Failed.Tests.dll"
The output should give you the problem which actually makes the tests fail. In my case it turned out that the new project had a reference to Ploeh.AutoFixture with a different version than the version used in the other unit test projects.
Unable to load the test container 'C:\BuildAgent\temp\buildTmp\Out[NAME TIMESTAMP]\Assembly.With.Failed.Tests.dll' or one of its dependencies. Error details: System.IO.FileLoadException: Could not load file or assembly 'Ploeh.AutoFixture, Version=3.18.10.0, Culture=neutral, PublicKeyToken=b24654c590009d4f' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).
Specific problem solution
In case you're wondering how to fix a similar issue, you can do the following. Open the package manager console (View -> Other windows -> NuGet Package Manager) and execute the following command.
Install-Package Ploeh.AutoFixture -Version 3.18.10.0
This adds the NuGet package (to the project selected on the dropdown) with a specific version, just make sure that all the projects are aligned in this sense.
I have a test class and below I have posted a sample test from the test class
namespace AdminPortal.Tests.Controller_Test.Customer
{
[TestClass]
public class BusinessUnitControllerTests
{
private IBusinessUnitRepository _mockBusinessUnitRepository;
private BusinessUnitController _controller;
[TestInitialize]
public void TestInitialize()
{
_mockBusinessUnitRepository = MockRepository.GenerateMock<IBusinessUnitRepository>();
_controller = new BusinessUnitController(_mockBusinessUnitRepository);
}
[TestCleanup]
public void TestCleanup()
{
_mockBusinessUnitRepository = null;
_controller.Dispose();
_controller = null;
}
#region Index Action Tests
[TestMethod]
public void Index_Action_Calls_GetAllBusinessUnit()
{
_mockBusinessUnitRepository.Stub(x => x.GetAllBusinessUnit());
_controller.Index();
_mockBusinessUnitRepository.AssertWasCalled(x=>x.GetAllBusinessUnit());
}
}
}
When I run the project I get following screen
I checked the references and the test project has the reference to main project.
Any idea why the test are not running or saying that they were inconclusive?
Edit 1:
I saw a post here and changed my test's setting's default processor architecture to X64 but it still doesn't work.
Just in case none of the above options worked for anyone I fixed my instance of this error by noticing a corrupt entry in my App.Config due to a missing nuget package in the test project.
For me it was rather frustrating, but I've found solution for my case at least:
If your TestMethod is async, it cannot be void. It MUST return Task.
Hope it helps someone :)
I had the same issue with resharper and I corrected this error by changing an option:
Resharper => Options => Tools => Unit Testing
I just had to uncheck the option "Shadow-copy assemblies being tested"
It was a Resharper issue. In Resharper options->Tools->MSTEST, I unchecked the Use Legacy Runner and now it works.
I faced this problem in vs 2017 update 3 with Resharper Ultimate 2017.2
Restart vs or restart machine can't help.
I resolved the problem by clearing the Cache as follows:
Resharper ->options-> Environment ->click the button 'Clear caches'
Update:
There is a button "error" (I find in Resharper 2018) in the upper right corner of the test window.
If you click the error button, it shows an error message that may help in resolving the problem.
To track the root of the problem, run Visual Studio in log mode. In vs 2017, Run the command:
devenv /ReSharper.LogFile C:\temp\log\test_log.txt /ReSharper.LogLevel Verbose
Run the test.
Review the log file test_log.txt and search for 'error' in the file.
The log file is a great help to find the error that you can resolve or you can send the issue with the log file to the technical support team of Resharper.
For me, simply cleaning and rebuilding the solution fixed it.
I was having this problem, and it turned out to be the same as this problem over here. This answer solved the problem for me.
Uncheck "Only build startup projects and dependencies on Run" (Options -> Projects and Solutions -> Build and Run)
In Configuration Manager, make sure both the start-up project and the Test project have "Build" checked.
The second time I hit this issue, it was due to an ampersand in the filepath to the project where the tests reside. It works fine with ReSharper's test runner, but not dotCover's. Remove the ampersand from the filepath.
This is a confirmed bug with dotCover.
For me, the problem was a corrupt NUnit/ReSharper settings XML-file (due to an unexpected power shortage).
To identify the error I started Visual Studio with this command:
devenv.exe /ReSharper.LogFile C:\temp\resharper.log /ReSharper.LogLevel Verbose
Examining the file revealed the following exception:
09:45:31.894 |W| UnitTestLaunch | System.ApplicationException: Error loading settings file
System.ApplicationException: Error loading settings file ---> System.Xml.XmlException: Root element is missing.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.Load(String filename)
at NUnit.Engine.Internal.SettingsStore.LoadSettings()
--- End of inner exception stack trace ---
at NUnit.Engine.Internal.SettingsStore.LoadSettings()
at NUnit.Engine.Services.SettingsService.StartService()
at NUnit.Engine.Services.ServiceManager.StartServices()
at NUnit.Engine.TestEngine.Initialize()
at NUnit.Engine.TestEngine.GetRunner(TestPackage package)
at JetBrains.ReSharper.UnitTestRunner.nUnit30.BuiltInNUnitRunner.<>c__DisplayClass1.<RunTests>b__0()
at JetBrains.ReSharper.UnitTestRunner.nUnit30.BuiltInNUnitRunner.WithExtensiveErrorHandling(IRemoteTaskServer server, Action action)
Note that this is NOT the test project's app.config!
A quick googling around identified the following file as the culprit:
%LOCALAPPDATA%\NUnit\Nunit30Settings.xml
It existed, but was empty. Deleting it and restarting Visual Studio solved the problem.
(Using Visual Studio Professional 2017 v15.3.5 and ReSharper 2017.2.1).
My problem was that I had only installed NUnit with nuget. I hadn't installed NUnit3TestAdapter which was also required.
Install-Package NUnit3TestAdapter
I just fixed this issue as well. However, none of the solutions in this thread worked. Here's what I did:
Since R# wasn't giving any detail about why things were failing, I decided to try the built-in VS2013 test runner. It experienced the exact same behavior where none of the tests ran. However, looking in the Output window, I finally had an error message:
An exception occurred while invoking executor
'executor://mstestadapter/v1': Object reference not set to an instance
of an object.
This led me to another thread on SO with a solution. Believe me, I would have NEVER guessed what the issue was.
I had recently made a few changes to the AssemblyInfo.cs file while creating a NuGet package. One of the changes including specifying an assembly culture value of "en".
I changed this:
[assembly: AssemblyCulture("")]
to this:
[assembly: AssemblyCulture("en")]`.
That was it! That's what inexplicably broke my unit tests. I still don't understand why, however. But at least things are working again. After I reverted this change (i.e. set the culture back to ""), my tests began running again.
Hope that helps somebody out there.
In my case i got this error because of 'Release' mode where build of UnitTests project was simply switched off. Switching back to 'Debug' mode fixed it.
It's really surprising that ReSharper cannot say anything in case it cannot find UnitTests library at all. Seriously, it's a shame;)
Hope it will help somebody
In my case [Test] methods were just private. S-h-a-m-e
This error occurred with Visual Studio 2017 and resharper version 2018.2.3 but the fix applies to Visual Studio 2019 versions to.
The fix, to get tests working in Resharper, was simply to update to the latest version of Resharper (2019.2.1) at the time of writing.
In my case it was a mistake i did while copying the connectionstring in the app.config..
I had put it inside the configSections tag!
Took me a while to realize that... thanks VS intellisense though.. or was it resharper?
I had similiar issue. VS 2010, c# CLR 2 Nunit 2.5.7 , just build > clean solution from VS helped to resolve this issue
In my case I created an async test method which returned void. Returning of Task instead of void solved the issue.
In my case, all tests within some test projects within a solution started not running after I added new projects. Using VS 2017 with ReSharper 2017.1.2 here.
First of all, make sure you're not wasting time assuming that your issue is ReSharper related. It is easy to assume that there's something wrong with ReSharper if you use its unit testing features including Unit Test Explorer. Open up Visual Studio's Test Explorer under the Test menu and try Run All". The added advantage of doing this is that the output window will show an error message that might point you in the right direction. If you notice that the same set of test are not run, then it is safe to assume that the issue is with Visual Studio and not ReSharper.
I ended up deleting and re-adding one of the Active solution platform, Any CPU, in Configuration Manager. By doing so, after saving my changes and reopening the solution, all tests started running again.
I believe there was an unexpected configuration entry in the solution file when I added new projects and by using recreating one of the platforms, it corrected itself. I tried diffing but it was difficult to tell what had changed to cause the issue.
Have you added any DLL dependency recently? ... like me
I just ran into the same issue and it was very exasperating not to get any clue in the test output window or elsewhere practical.
The cause was extremely stupid: I just added the day before dependency to an additional external DLL in a sub-project, and the main project App indeed built and ran correctly after the change. But my unit tests are in a sister project to the main app, and thus had too the dependency on this changed sub project where the DLL was invoked... yet, the runtime location of the test project is not that of the main App!
So changing the build to do copying of the missing DLL into the test runtime directory fixed the problem.
I am using VS2013, ReSharper 9.1 with MSpec extension from ReSharper and Moq. I experienced the same "inconclusive" error.
It turned out the one of my Mock's from Moq was not initialized, only declared. Ones initialized all tests ran again.
In my case my test method was private I changed it to public and it worked.
For those who are experiencing this issue for my test project .NET Core 2.0 in the Visual Studio 2017 Community (v15.3 3). I also had this bug using JetBrains ReSharper Ultimate 2017.2 Build 109.0.20170824.131346 - there is a bug I posted.
JetBrains advised to create a new test project from scratch to reproduce it. When I did that and got tests working OK, I found the reason causing the issue:
Remove this from your *.csproj file:
Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}"
When I did that - tests started working fine.
For who are in rush for test execution, I had to use VS 2017 test explorer to run tests;
I'm using VS2010, NUnit 2.6.3 (although internally ReSharper says it's using 2.6.2?), ReSharper 7.7.1 & NCrunch 2.5.0.12 and was running into the same "...test is inconclusive..." thing with NUnit, but NCrunch said everything was fine. For most of today NUnit & NCrunch were in sync agreeing about which tests were happy and which needed refactoring, then something happened which I still don't understand, and for a while NCrunch said I had failing tests (but stepping through them showed them to pass), then decided they were all working, and NUnit started complaining about all my tests except one with the same message "..test is inconclusive..." which I was again able to single step through to a pass even though NUnit continued to show it as "inconclusive").
I tried several of the suggestions above to no avail, and finally just closed VS2010 & reopened the solution. Voila, now all my tests are happy again, and NCrunch & NUnit are reporting the same results again. Unfortunately I have no idea what changed to cause them to go out of sync, but closing & reopening VS2010 seems to have fixed it.
Maybe someone else will run into this and be able to use this simple (if ultimately unsatisfying since you don't know what the real fix is) solution.
I had this same issue. The culprit was an external reference not being compatible with my project build settings. To resolve, I right clicked on the project->properties->build->Platform Target-> change from Any CPU to x86.
The particular *.dll that I was working with was System.Data.SQLite. That particular *.dll is hardcoded for 32 bit operation. The "Any CPU" setting attempted to load it as 64 bit.
My solution:
NUnit 3.2.0 has some issues with Resharper - downgrade to 2.6.4:
update-package nunit -version 2.6.4
Caused by missing (not corrupt) App.Config file. Adding new (Add -> New Item... -> Application Configuration File) fixed it.
I had the same problem.It was related to compatibility version between NUnit 3.5 and Resharper 9.2,since it was solved by downgrading from NUnit 3.5 to 2.6.4.
It worked for me.
good luck.
If you are using xUnit, I solved the issue installing xunit.running.visualstudio package.
(currently using xUnit 2.3.1 and VS17 Enterprise 15.3.5)
I'm was having the same problem to run any test using NUnit framework. "Inconclusive: Test not run"
Visual Studio 2017 15.5.6
ReSharper Ultimate 2017.3.3 Build 111.0.20180302.65130
SOLVED Adding project dependency to Microsoft.NET.Test.Sdk
I had the exact same problem, no tests were run in my test-project. As it happend I had the wrong configuration selected when running the tests. Changing it back to Debug fixed the problems.
When running MSTest from Visual Studio - the unit test execution time is relatively quick.
When running MSTest from the command line, with /testsettings flag - the execution takes forever and that is because it spends 95% of its startup time copying the dll's to its Out folder. Is there a way to prevent this?
The default Local.testsettings in the project has no modifications to it (which also means it is empty). However, if I try to use that same file from the command line, MSTest complains about missing DLL's that the Unit Test reference.
Have you tried disabling deployment in the test settings? When it is disabled, the tests should be run in-place rather than on copied assemblies. (See http://msdn.microsoft.com/en-us/library/ms182475.aspx for details.)
try MSTest.exe /noisolation http://msdn.microsoft.com/en-US/library/ms182489.aspx
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.