There is a problem with Visual Studio 2010 test runner. Today I've loaded test results from night build on build server. Exproted this results to *.trx file, removeed from it information about test agent to run test localy. And than imported this file to VS Test Result window. After try of run failed tested, I received message One or more tests could not be found and message Test ... has not been loaded and cannot be added to the test run.
What does it mean? What is the problem?
I've created my project with tests like Class Library Project, not like Test Project. Can it be a reason of error?
PS. I tryed to add image with this error, but I need more reputation.
I can upload image to external resource, if it'll be able to help to solve my problem.
Yes you are right.
If you use MsTest and want to use Visual Studio 2010 test runner, your tests should be placed into a project created like Test Project.
There is a discussion on MSDN Forum on converting project to Test Project.
I suggest you to create new Test Project.
It is the easiest solution.
Otherwise you have to edit *.csproj file and add Guid {3AC096D0-A1C2-E12C-1390-A8335801FDAB} inside ProjectTypeGuids.
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Create new project and cut and paste files in new project
restart VS
Related
Created a simple framework with Scenario Outline tests, it can be found here. Copied allureConfig.json file into bin/debug directory. Nuget versions:
Nunit 3.9.0;
SpecFlow 2.3.0;
SpecFlow.Allure 2.2.0.11;
Net framework 4.6.2.
After tests execution, using search, I found test-results directory in the next location:
C:\Users\Valentins\AppData\Local\Temp\allure-results
And it contains just .json files, like:
52bb84abaec342e1bf8e7fbc3e46a181-container
and
9ab91b6fc6e84eafbda735c49ccfcb1c-result
Can anyone help to understand, how to make this folder to appear in the tests and how to normally open Test results to see it in Html file?
Thanks in advance,
Valentins.
The problem was because I was running tests, using Visual Studio. When I started to run, using CI server (TeamCity), then allure-results folder appeared in the Project, but for creating a report, allure-commandline-tools were needed.
I have a project with classes and methods that I want to test. I have another project with the test methods that will test the methods of my main project.
I run the tests with opencover and I generate the reports with reportgenerator, with this commands that I have in a .bet file:
..\tools\OpenCover.Console.exe -register:user -target:"C:\myDllWithTests.dll" -output:"c:\coverage\opencovertests.xml"
.\ReportGenerator.exe "-reports:c:\coverage\opencovertests.xml" "-targetdir:c:\coverage\opencovertests.xml\reports"
I am using MSTest for testing.
The problem is that in the html report, I see that the code that is covered is the tests methods, not the methods in my test main project.
How I could add the main methods in the result?
Thanks.
In target argument for OpenCover pass the path to MSTest (e.g. "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest.exe") and specify your test assemblies (e.g. "C:\myDllWithTests.dll") in targetargs argument.
To remove test assemblies from code coverage statistics, specify them in filter argument.
Below is OpenCover command that works fine for me. Here code under test is placed in SampleApp.dll and test code is placed in SampleApp.Tests.dll.
.\OpenCover.Console.exe -register:user -mergebyhash -target:"c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest.exe" -targetargs:"/testcontainer:\"d:\test\SampleApp\SampleApp.Tests\bin\Debug\SampleApp.Tests.dll\"" -output:UTResults.xml -filter:"+[SampleApp*]* -[SampleApp.Tests]*"
Result report contains only stats for SampleApp.dll assembly, SampleApp.Tests.dll is excluded:
Check this answer for some more details.
There is also a great article by Allen Conway on using OpenCover & ReportGenerator for .Net projects.
This might be quite a late answer here, but I've spent an hour or two playing with this and found the following will fix this. It's worth noting that I had the original bat script from another project that I know works, and just changed the DLL file name, so I know the script was OK.
The additional check to make is to:-
Right click the project that has the source code you want visible in the coverage report (not the unit test project) and click Properties
Select Build > Output > Advanced
Set Debugging information to Full
Rebuild solution and re-run bat file.
Works for me in Visual Studio 2019 with .NET Framework 4.7.2 projects.
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>
This is a follow-up to this question. I followed the steps as described here and the sample tests work as expected. This is the first time I got to this working sample, but wait for the real working setup which is where I am having trouble.
As a next step to testing my app, I added my UWP app project using "Add Reference..." to the xUnit Test project. Now, after I referencing my project, when I run the test (Run All in Test Explorer pane VS2015) I get the following error:
Error Payload contains two or more files with the same destination path 'Assets\SplashScreen.scale-200.png'. Source files:
...\Projects\Sample\SampleUnitTest\Assets\SplashScreen.scale-200.png
...\Projects\Sample\Sample\Assets\SplashScreen.scale-200.png SampleUnitTest
There are two more errors, exactly as above, but referring to Square150x150Logo.scale-200.png and Square44x44Logo.targetsize-24_altform-unplated.png image files.
I can understand what these errors mean; the app being tested and the test project both generate visual resources (splash-screen image, logo, taskbar icon, etc.) destined for the same output but these are required to register the app(s) and run (on a local machine in my case). I've never come across such a contentious issue of two projects outputting the same visual resources and hopefully someone knows how to solve this. The unit test doesn't work if I change the project to Class project, so that is not an option.
How do you deal with the contentious situation (wrt visual resources) between an xUnit test project and a project being tested?
Okay, I figured out how to resolve the conflict between the visual resources residing in the Assets folder, but this leads to a new kind of issue for the xUnit (which will be my follow-up question).
For the xUnit project, rename the Assets folder to, say, Images (or whatever you think is a better alternative name).
Point to the Package.appxmanifest file under xUnit project and open it as a code file. To do this, select the Package.appxmanifest file and press F7, or right-click the file and select the View Code context menu command.
In the code file, replace the folder name Assets with Images or whatever you chose to rename the Assets folder with. Save it.
Now the test project will compile and run with no visual resources output conflicts. With regard to xUnit however, we'll hit another problem as described in my next question.
I changed the output path of the test project, because the default path doesn't conform to our projects directory structure. After I did that, Visual Studio 2008 fails to run the tests, because it can't find the Unit Test project assembly.
What else do I have to change for the Unit Test Engine to find the assembly?
There are at least three ways to solve this problem
Set up the output path before you run any test in the solution (as suggested by Paulius Maruška).
Close the solution, delete the directory TestResults (under your solution folder) and then open the solution and run all tests (Test -> Run -> All...)
Add your assembly to the list of files to deploy in the .testconfig file (suggested by Ty)
Solution number 3 is probably not recommended, since solution 1 or 2 will achieve the same
without adding a second reference to the output path.
Please note that solution number 2 will delete any test history you may have.
If you open up your .testrunconfig file and go to the Deployment option, you can add your test assembly to the list of files to deploy. You should then be able to run your tests.
I figured this out, I think.
This is the only solution I have found. Adding the assembly to the files to deploy list (as suggested by Ty) works, but it kind of feels dirty, so I didn't want to do that.
Visual Studio accepts the changed path, only when you change it before running any of the tests. So, the solution to my own question is: You have to create a new test project, change it's build path, add all of the tests from the old test project.
Close your project, then delete your hidden .suo file and the csproj.user file. Then re-open the project. That fixes it.