Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I've installed NUnit Test Adapter for VS2012 + 2013. When I first installed the Adapter tests were showing up, but they stopped showing up for some reason today. After building, rebuilding, cleaning, restarting, nothing shows up in Test Explorer. Why would this be happening? I'm using VS2013 Ultimate.
If you're using a NUnit3+ version, there is a new Test Adapter available.
Go to "Tools -> Extensions and Updates -> Online" and search for "NUnit3 Test Adapter" and then install.
If your test project is set to target a 64bit platform, the tests won't show up in the NUnit Test Adapter.
My test assembly is 64-bit. From the menu bar at the top of visual studio 2012, I was able to select 'Test' -> 'Test Settings' -> 'Default Processor Architecture' -> 'X64'. After a 'Rebuild Solution' from the 'Build' menu, I was able to see all of my tests in test explorer. Hopefully this helps someone else in the future =D.
Check for NUnit versions mismatch. The currently available NUnit Test Adapter only works for NUnit version 2.6.4 and below.
To downgrade NUnit from version 3.x go to
Package Manager Console > update-package NUnit -version 2.6.4
http://jeremybytes.blogspot.co.ke/2015/11/review-of-unit-testing-makes-me-faster.html
In my situation the 'NUnit3 Test Adapter' has been disabled.
To re-enable it go to menu
Tools->Extensions and Updates...
On the left side select 'Installed'->'All'.
On the upper right corner search for 'nunit'.
If you have 'NUnit3 Test Adapter' installed, with the found item you can enable/disable it.
This answer seems pretty basic but wasn't completely obvious to me at first. If you (re)build the solution it only builds the projects that are configured to build in the Build -> Configuration Manager
This was my issue, I must have inadvertently changed a build configuration settings or something that caused my test projects not to build (when they previously were). So the Test Explorer window was looking at dlls that were out of date. It became clear to me this was the case after doing a Clean and seeing most of my tests disappear and not come back after a rebuild...further inspection of bin folder showed that these projects weren't being built at all.
I had a working setup (for NUnit2 and NUnit3 depending on the solution, and multiple versions of Visual Studio between 2012 and 2017), and it suddenly stopped working one day: no tests detected in any solution or version of VS.
In my case, it helped to delete %localappdata%\Temp\VisualStudioTestExplorerExtensions. After a restart of VS, everything worked as before.
If you are using VS 2017 and .net core ,as said here, you should add references to the test framework NUnit 3.6.1, to the test runner NUnit3TestAdapter 3.8.0-alpha1 and to the test SDK Microsoft.NET.Test.Sdk 15.0.0.
Tools
NuGet Package Manager
Manage NuGet Packages For Solution
Browse
NUnitTestAdapter.WithFramework
Ctrl+R,A to build/run tests
Using NUnitTestAdapter.WithFramework makes sure there are little/no inconsistencies across versions of NUnit and NUnit Adapter (i.e. "it just works")
Check whether you have stated
[TestFixureSetUp]
and
[Test]
in the test class
sample:
namespace ClassLibrary1
{
public class SimpleCalculator
{
public Calculator _calculator;
[TestFixtureSetUp]
public void initialize()
{
_calculator = new Calculator();
}
[Test]
public void DivideTest()
{
int a = 10;
int b = 2;
int expectedValue = a/b;
int actualValue = _calculator.Divide(a, b);
Assert.AreEqual(expectedValue, actualValue, "Functionality not working properly!");
}
}
}
I had to uninstall then re-install the xunit.runner.visualstudio nuget package. I tried this after trying all the above suggestions, so may be it was a mixture of things.
One other cause to this problem is if you open a project from a mapped drive - Visual Studio handles such projects properly, but apparently Nunit doesn't support them.
Copying the project to a physical fixed the issue.
I also found that when I uninstalled nunit v3.2.1, the nunit framework reference for v3.2.1 was still in my project in solution explorer.
Solution Explorer > ProjectName > References
If you right click it will show the version. Remove this
Then Right click on References > Add Reference.
Search for the version 2.x version and add then rebuild solution.
That worked for me!
I experienced the problem mentioned by op
My case was that I was handed an old project and the tests were actually part of the system under test. I assume they were using the external test runner.
this task chain resolved the issue for me
created a test project,
moved the test files there
added references so the test project would compile
added the Nunit and Nunit adapter NuGet packages to the test project
recompiled
i was able to successfully run the Nunit tests.
If you are using the TestCaseSource attribute, ensure the source exists and respects the documentation, otherwise your tests will not be discovered.
I had a similar issue where the tests where not being discovered. I had the correct version of NUnit, versions matched up between NUnit and adapter, and the tests where tagged correctly. I was running VS 2017 Enterprise not as an administrator. After starting VS as administrator the tests appeared.
I started a new solution with a test project in it, and compared it against my original, problem project. The original, for some reason, had an app.config in it. I excluded that file from the project and saw my tests reappear in the test explorer.
I had this problem too but the cause was different. I'm using VS2017 with F# 4.0.
Firstly, the console in Visual Studio does not give you enough details why the tests could not be found; it will just fail to the load the DLL with the tests. So use NUnit3console.exe on the command line as this gives you more details.
In my case, it was because the test adapter was looking for a newer version of the F# Core DLL (4.4.1.0) (F# 4.1) whereas I'm still using 4.4.0.0 (F# 4.0). So I just added this to the app.config of the test project:-
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="4.4.0.0" />
</dependentAssembly>
i.e. redirect to the earlier F# core.
I had the same problem, when suddenly any test didn't appeared on Test Explorer window.
I has the updated version of "NUnit3TestAdapter"
and after lots of searches and efforts,
I found that I need set the following values in project properties:
[In Solution Explorer window: right click on Project > Properties]
Under Build tab, set Platform=x64, and set Platform target=x86 or Any CPU
Build the project and all tests will be appear on Test Explorer window.
Important note:
I came to a solution after seeing the next msg in the output window:
"Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run: AutomationTests.dll is built for Framework Framework45 and Platform X64."
I had some msbuild.exe processes that were hung. I don't know if that was my problem or not, but it took me a lot of trail and error with reinstalling various NUnit adaptors before I found the hung processes.
Just to add my $.02 here, I ran into a similar issue just yesterday, where 168 of my tests were missing. I tried most everything in this post - most especially making sure my version(s) of NUnit were the same - all to no avail. I then remembered that I had my tests divided into playlists; and these do not update automatically as you add new tests. So, when I deleted the playlists, BAM!, all of my tests were back once more.
I use NUnit 3 and tried most of the other solutions I saw here. None of those worked for me.
Even though already selected, reselecting the "Playlist: All Tests" option in test explorer showed all hidden tests in my case. I need to do this after every rebuild.
Make sure your test class is public. I often make this mistake then I just look at the code for 5 minutes what is going on.
[Test]
public void YourTest()
{
...
}
Tools
NuGet Package Manager
Manage NuGet Packages For Solution
Browse
NUnit3TestAdapter (NUnit 3 in my case ..)
After installation it should be possible to use the default TestExplorer included with the installation of Visual Studio.
If your test project is not x86, the tests will not be found until you tell the test runner the correct target platform.
Prior to Visual Studio 2022, this was the "Test/Test Settings/Default Processor Architecture" option.
In VS2022 you need to create a 'runsettings' file and set the test project to use it. In that file you can specify the Target Platform, like this:
<?xml version="1.0" encoding="utf-8" ?>
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<TargetPlatform>x64</TargetPlatform>
</RunConfiguration>
</RunSettings>
You still also need to include the Nunit3TestAdapter and Microsoft.NET.Test.Sdk nugets (and make sure the project actually built, and check the various other more obscure mistakes mentioned in other answers)
Make sure your tests are properly marked with the Test attribute. If all of the tests are marked with only the Explicit attribute, the TestAdapter doesn't recognize the fixture.
I remember doing this in an older version of Team City in which the NUnit Runner failed, so I tried running NUnit using the Command Line Runner instead.
I think there was an option in the Command Line Runner settings which let you specify the kind of output file: NUnit result.xml was one of them. Doing this, you could see the test result breakdown in the Web GUI, just like when the NUnit Runner worked.
But I don't see this in the latest Team City (6.5.5). Can it still be done?
PS: Before anyone asks, I can't use Team City's NUnit Runner because NUnit has a bug which will be fixed in the soon to come 2.6.0 version. Said bug does not occurr when running nunit-console
This could be done using importdata TeamCity message, this is really helpful when you are running NUnit tests manually executing nunit-console.exe from an MSBuild script, for instance using NUnit MSBuild Community Task, but keep in mind that TeamCity provides built in NUnit tests runner so you do not need this low level TeamCity scripting. Anyway you can import report in this way:
<Message
Text="##teamcity[importData type='nunit' path='...\TestResults.xml']"
Importance="High"/>
See Importing XML Reports
If you prefer to run code coverage, code inspection, test tools or
duplicate finders directly from build script, not as a build runner,
you can use the importData service messages to import generated xml
reports into TeamCity.
The functionality was still there, found it by accident when looking at another build configuration. Importing an XML is now a "Build Feature", see:
Well we are facing a strange problem with JetBrains TeamCity induced unit tests on our main project where tests from few library projects are failing regularly. Apparently, it's not reading the config file (coming from app.config and nicely stored in project -> bin -> debug -> projectName.dll.config).
Hints or tips on what could be the real issue would be highly appreciated.
I've got the same problem and wasted a couple of hours to figure out what the problem is.
In our case, the NUnit plugin was configured to run the tests from:
**\*Tests.dll
Though this sounds to be OK, it has turned out that this pattern will not only match to the MyTests.dll in the bin\Debug folder but also to the obj\Debug\MyTests.dll. The obj folder is used internally for the compilation and does not contain the config file.
Finally the solution was to change the plugin configuration to
**\bin\Debug\*Tests.dll
Actually we use a system variable for the build configuration so we did not have the "Debug" hard-coded. Using bin* might be also dangerous when the workspace is also used for Debug/Release builds and you don't have a full cleanup specified.
You might wonder why I did not realize the test count mismatch (actually it was doubled, because they were running once from bin and once from obj), but this is typical: while everything is green, you don't care about the count. When we have introduced the first test depending on the config, we had only one failure (because the one from bin was passing), so the duplication was not outstanding.
In addition to Gaspar Nagy's accepted answer, check to see if your project has multiple test dlls and one of them is referencing another.
This causes the referenced dll to be run twice, and the copy that was in the other dll's folder to not have the proper app.config entries. The proper fix is to remove any and all references from the other test project.
TeamCity (v6.5.4) has its own NUnit Test Runner and there seems to be an inconsistency between it and the NUnit GUI test runner (2.5.10). The NUnit GUI Test Runner follows the long standing convention of expecting the configuration file name to be of the format .config. You can see this in NUnit by looking at Project -> Edit...
TeamCity on the other hand is looking for an app.config.
Your options are to either:
Set the NUnit GUI to point to app.config and include the resultant
nunit project in your source control.
Have both an app.config and a .config - syncing both
manualy.
Add a step to your build process to copy .config to
app.config (or vice versa).
I had similar woes
This may help; additionally we had issues where this still would not work - we ended up copying the relevant config sections into the highest level config file. (i.e. if it was a web app copy it into the Web.Config) - fairly kludgy but we had wasted a few days on the issue
I learned recently that app.config files are not read for a class library... Maybe this link could help :)
app.config for a class library
If you need a config file for your "unit" tests then you are doing it wrong. Proper unit testing never needs configuration or access to the database, file system etc. You should change your testing strategy.
Good point to start is mark your tests that need configuration with the[Category("Integration")] annotation and set the Teamcity test runner to ignore this category. Then you should focus on refactoring these test.
Basically I'd like to use the NUnit plugin for TeamCity (the program, not necessarily the specific build step using it) to run my unit tests, with NCover for code coverage, and since my unit tests uses TypeMock 6, I need that too working.
So far I've tried:
Just basically pointing the TeamCity NUnit build-step to my dll's, but that fails with the following error message:
Typemock Isolator needs to be linked with Coverage Tool to run, to enable do one of the following:
link the Coverage tool through the Typemock Isolator Configuration
run tests via TMockRunner.exe -link
use TypeMockStart tasks for MSBuild or NAnt with Link
Trying to figure out the right command line, I tried this:
C:...\Isolator\6.0\TMockRunner.exe "C:\TeamCity...\JetBrains.BuildServer.NUnitLauncher.exe" v4.0 MSIL NUnit-2.5.9 MyAssembly.dll
This fails with the exact same error.
Setting the environment variables found in the mocking_on.bat file part of TypeMock, this doesn't change the outcome.
Note that the above examples doesn't contain any reference to NCover (yet), that's because I've been hacking around on the command line for a couple of hours with the above examples and still haven't gotten basic unit-tests running. NCover is extra options to the nunit-launcher of TeamCity so I hope this is as simple as just enabling that when I get that far.
Since TypeMock requires you to use their own runner program, TMockRunner, there's no way to just use the GUI options in TeamCity to get everything set up.
Instead, what I ended up doing was to first build a custom msbuild file with this contents:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TypeMockLocation>C:\Program Files (x86)\TypeMock\Isolator\6.0</TypeMockLocation>
<NUnit>"C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.NUnitLauncher.exe"</NUnit>
<NCover>C:\Program Files (x86)\NCover\NCover.Console.exe</NCover>
</PropertyGroup>
<Import Project="$(TypeMockLocation)\TypeMock.MSBuild.Tasks"/>
<Target Name="TestWithTypeMock">
<TypeMockStart Link="NCover3.0" ProfilerLaunchedFirst="true" Target="2.0"/>
<Exec ContinueOnError="true" Command="$(NUnit) v2.0 x86 NUnit-2.5.9 SqlDatabases.Core.Tests\bin\Debug\SqlDatabases.Core.Tests.dll SqlDatabases.SqlServer.Tests\bin\Debug\SqlDatabases.SqlServer.Tests.dll /ncover:%22$(NCover)%22 /ncover-arg://ias /ncover-arg:SqlDatabases.Core /ncover-arg://ias /ncover-arg:SqlDatabases.SqlServer /ncover-arg://et /ncover-arg:.*Exception /ncover-arg://x /ncover-arg:c:\temp\coverage.xml"/>
<TypeMockStop/>
</Target>
</Project>
This file I save to a directory on my TeamCity server. Since I didn't want the test script to be part of my repository, I didn't add it to source control (I can build and right-click and run tests from within Visual Studio, if I get something not so tied to my build server I might change that decision later). Also, I only have 1 build-agent for my TeamCity server so this works for me for the time being.
In addition to the above file, I added the following batch-file:
#echo off
setlocal
set CURDIR=%CD%
copy c:\dev\sqldatabases\tests.msbuild .\
msbuild tests.msbuild /target:TestWithTypeMock
rd /s /q c:\dev\sqldatabases\codecoverage
md c:\dev\sqldatabases\codecoverage
"c:\program files\ncover\ncover.reporting.exe" c:\temp\coverage.xml //or FullCoverageReport:Html:c:\dev\sqldatabases\codecoverage
cd \dev\sqldatabases\codecoverage
del %CURDIR%\coverage.zip
7z a -r %CURDIR%\coverage.zip
And then I added the following two build-steps to my TeamCity build configuration:
Visual Studio Solution: Build the debug configuration.
Execute C:\Dev\SqlDatabases\Tests.bat (the above batch file)
I made sure that coverage.zip was listed under artifacts in my build configuration, and now I got code coverage, typemock, and unit tests.
Only thing I haven't figured out how to get so far is that if I click on the build result of a build configuration that uses the normal TeamCity GUI for setting up everything (minus TypeMock), I get a code coverage short summary listed, this is not present in the above setup, but the full report is, and the tab in the TeamCity build results.
Hopefully this can save someone else some trouble.
Lasse,
So long as you're using the TeamCity GUI, running with NCover coverage should just be a simple matter of selecting to run with it.I've never tried throwing Typemock into the mix, so I look forward to hearing how that goes.
We recently upgraded CruiseControl.Net 1.4.2 to 1.5.7256.1. To our dismay the nice nunit results page that had previously been there had disappeared. All we get now is a build log with the verbose output from command line of our build.
After some research we discovered you can log into "Dashboard Administrator" from the main ccnet dashboard page and install the NUnit package. However, this did not change the output of our builds to include a NUnit result page.
Is there something extra we need to do here to have our output displayed? Any help would be greatly appreciated. I don't goto stack overflow until I've exhaustively searched on Google. I'm surprised no one else is confused or complaining about this.
FYI, we are merging our nunit XML output in the project configuration.
I'm not used to the Dashboard Administrator stuff, but you can edit the dashboard.config manually. Opposite to earlier versions CCNET version 1.5 comes with a naked configuration file.
Alternatively you may simply replace the configuration file with your 1.4 dashboard.config.
Possible duplicate of Cruise Control .net: Using packages and showing NUnit results
Don't merge manually if you use the nunit task
Edit the dashboard.config and the ccservice.exe.config files to add the nunit xsl files. Restart IIs.
Check that the Iis user has been granted access to the dashboard dir.