I have a very simple MSTest unit test project that indirectly have dependency on two versions of MVC.
assemblybinding in app.config is configured to redirect to MVC v4
when I run mstest test runner (VS2012 RC built-in) - I get exception indicating that assembly binding did not work.
If I create testsettings file and disable deployment (or enable deployment and add app.config to the list of items to deploy) - test passes.
Question: why does assemblybinding works with deployment set to false? Can I make this test pass without using testsettings file?
I am experiencing the same thing with vs2012, mstest and R#, seems to be a confirmed bug according to this:
http://social.msdn.microsoft.com/Forums/en-US/vsunittest/thread/234926d1-42c0-4ebb-af39-1626e72f6c39
Adding link to the same bug report in R#:
http://youtrack.jetbrains.com/issue/RSRP-329567
Related
We are using VSTS to perform Continuous Integration utilizing a build template that was created to deploy a website to a Dev machine.
This worked fine but then we wanted to add in CodedUI tests to the build template in order to run the tests as part of the build step.
So I added a Visual Studio Test step to the build and added in the test by referencing the test plan and test suite it was associated with.
I made sure the codedUI project was built within the same solution as the website in order to make sure the binaries were built with it.
The problem I'm getting is that when the build runs it brings back errors stating that it is missing the relevant references for the code to work such as:
QualityTools.CodedUITestFramework
QualityTools.Common
TestTools.UITesting
etc.
However these reference are included in the project and "Copy Local" is set to true.
Does anyone have any idea what could be going wrong?
UPDATE
New error received:
MSTestAdapter failed to discover tests in class
'Email_Regression.CodedUITest1' of assembly
'C:\agent_work\4\s\Microservices\Email\Email
Regression\obj\Release\Email Regression.dll'. Reason Could not load
file or assembly
'Microsoft.VisualStudio.QualityTools.CodedUITestFramework,
Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified..
No test is available in C:\agent_work\4\s\Microservices\Email\Email
Regression\bin\Release\Email Regression.dll
C:\agent_work\4\s\Microservices\Email\Email
Regression\obj\Release\Email Regression.dll. Make sure that test
discoverer & executors are registered and platform & framework version
settings are appropriate and try again.
After talking to the Microsoft help team it appears that you need to have Visual Studio Enterprise edition installed on the machine you wish to run the codedUI tests on.
Update
After discussions with Microsoft and highlighting this being a rubbish solution they are now going to deliver the dll's as part of the new vsTestPlatform installer. I'm not saying this is down to my complaints, just coincidental timing.
It happened in VS2010 that when creating project, .csproj file didn't generate some tag ProjectTypeGuids in the first PropertyGroup.
This had consequence that I couldn't see in TestView window any MS unit test in that project, nor execute it.
I copied ProjectTypeGuids from some other .csproj file where tests worked, and it worked, by explanation of MoCapitan in:
MSTest Not Finding New Tests
Does anyone knows what is ProjectTypeGuids, why UnitTests are not working without it and what is the reason for VS to generate or to omit it?
ProjectTypeGuids is list of "guid that identifies project type". So if you are missing "this is Unit test project" guid than default VS infrastructure will not try to look for tests in that project (other test runners like R# may still run such tests).
If you created project as regular "class library" (instead of "Unit tests project") than the guids will be missing.
Partial list of types: http://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
Trying to debug an NUnit test in VS2010 and is not stopping on the breakpoint. It was working the last time I tried need to debug the test (maybe 1 yr ago) but now it doesn't work.
I've tried the following:
How to debug with vs.net 2008 and nunit?
http://erraticdev.blogspot.com/2012/01/running-or-debugging-nunit-tests-from.html
I've tried attaching, rechecking my installation, updated the config file so it's using the 4.0 runtime, still doesn't hit the breakpoint.
What am I missing?
You can debug nunit tests in VS studio community version only. For this you need to install Nunit3testAdpter. You can add this in Tools -> Extension and updates. or from Nuget packages.
This is a long overdue question but I haven't seen the solution to debug NUnit tests directly within Visual Studio. This is quite easily possible and without any third party tools. All you have to do is configure your test project (which is just a plain old Class library project) so it will start NUnit test runner whenever you hit F5 or Ctrl-F5 (just run, no debugging).
Particularly you will have to configure your project properties to start an external program:
Step by step configuration is very well described in this blog post. It advises you to use NuGet to obtain NUnit test runner and configure project to execute the runner when you try running your library project. As simple as that. Using no specific tools which are usually not free.
There are multiple reasons why this may happen. If your application's target framework is different from NUnit's, then you won't be able to debug, because the tests are actually being run by nunit-agent.exe.
For me, my application was using 4.5, but NUnit's was using 3.5. (You can find this from one of the NUnit GUI applications -> Help -> About)
To fix this, change the nunit.exe.config file to include the following, inside the configuration section:
<startup>
<requiredRuntime version="4.0.30319" />
</startup>
This can also happen when your PDB generation is set to embedded. Switching it to full will allow the nunit test adapter to start with the debugger attached. At that point it can be switched back to embedded and it will debug again.
The setting is on the project properties pages, in the Build tab, then click the Advanced button. I always choose "All Configurations" at the top, so I make sure I'm emitting a useful PDB (or embedding the info) when building Release configuration assemblies too.
The other day I failed to hit a breakpoint in my NUnit debugging. It took me a while to realize that someone had copy/pasted the test into a different file and I was running a different test than the one that the breakpoint was in.
I recently had a similar problem. Changing the project's platform to AnyCPU solved it for me. Also worth checking:
1) Check NUnit's latest version (I was using 2.5.7, updated to 2.6.2)
2) The Target Framework for your test project. I was using .NET 4.0 (you can find it under Properties -> Application, on VS2010)
At least up to vs2010 the debugger can only debug 32 bit apps but not 64 bit apps.
With vs2010 I am using a 32bit nunit.exe version and use "attach to debugger". This workes well for me.
Please upgrade NUnit Test Extension and close the Visual studio so Visx (probably spell) will run and update NUnit tool.
After this you can open your project and run NUnit test project.
It will run.
I tested accurately.
Try changing the test to x64. From the menu do
Test -> Test Settings -> Default Processor Architecture -> x64.
i think u cant debug with Visual studio. better u install TestDriven.NET.
then
Put the BreakPoint on the test method
Right click on the test
method.
select TestWith->Debugger
I'm trying to run MSpec tests in Visual Studio's test system using Gallio, but it appears to be ignoring the MSpec plugin from the IDE. What I did:
Installed Gallio
Added the MSpec NuGet package to my test project
Added the Gallio NuGet package to my test project
Copied the three files required for the MSpec Gallio integration to an "MSpec" folder in Gallio's installation directory
Wrote an MSpec test
Ran "All Tests in Solution" in the IDE
This yielded the following error
"No tests were run because no tests are loaded or the selected tests are disabled"
To check Gallio itself, I added a reference to MbUnit and created a simple MbUnit test. I also ran Gallio's other tools to check if the plugin was being picked up at all. I even restarted VS for good measure.
Results
Running the tests using Gallio.Echo or Gallio.Icarus successfully executes both MbUnit and MSpec tests, so the plugin is being picked up. Running the tests from Visual Studio runs the MbUnit test but not the MSpec test, so Gallio integration appears to be working (just not the MSpec plugin). Any thoughts?
Before anyone mentions it: yes, I'd rather be using ReSharper but licenses are not an option for my situation at the moment.
Update: The is now a project to integrate MSpec into VS2012's test system. It's available on the Visual Studio Gallery and the source is on GitHub.
After starting to debug the problem with both project's sources, it appears there are two underlying issues causing the incompatibility between MSpec and Gallio's VS runner. However, both issues stem from the fact that the VS runner uses Cecil to load type information from assemblies (presumably to avoid loading the test assembly into the main VS AppDomain).
I'll update this answer as I uncover more (hopefully resulting in one or more patch to fix the issues).
Issue 1: Nested types are ignored
I had been using nested types for my tests (SubjectSpec+when_something), which are ignored by the Cecil-based reflection used by Gallio's VS runner to avoid loading the test assembly into the app domain.
This ended up being a relatively simple fix, which I've submitted as a patch to the Gallio developers. I'll update this answer if/when I get confirmation of which release it will be part of.
Issue 2: MSpec causes "An exception occurred while invoking a test driver"
If the container type is removed to avoid issue 1, MSpec throws this error. The reason for this is that MSpec is trying to create an instance of the test object, but Gallio is only supplying it a wrapper Type object that can't actually be created.
I have configured Specflow to target the MsTest framework (instead of NUnit) by specifying it like this in the app.config of my 'specs' class library:
<configSections>
<section name="specFlow"
type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
</configSections>
<specFlow>
<unitTestProvider name="MsTest.2010" />
</specFlow>
So once it's in place, I can see that my test fixtures are produced correctly by the Specflow custom tool, with correct TestClassAttribute() and methods, etc:
[System.CodeDom.Compiler.GeneratedCodeAttribute("TechTalk.SpecFlow", "1.3.3.0")]
[System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute()]
...
The specs class builds, but now I cannot run the tests using the Test --> Run --> All Tests in Solution inside Visual Studio 2010 on my vista 64 box. Why doesn't VS recognize these as valid tests to run?
As per Dror Helper and Alex Duggleby you'll want to add the following line to your .csproj file:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Add it after the FileAlignment element, and reload the project. It should now be an MS Test project and you get the MS Test functionality in the context of this project. The Guids mean:
{3AC096D0-A1C2-E12C-1390-A8335801FDAB} - Test Project
{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} - C# Class Library
I had to recreate the project as a Test Project and not merely a Class Library -- because I had started development with NUnit and SpecFlow, I had created a vanilla class library to hold my specs that had the NUnit attributes decorated. I thought I could simply change the app.config of this existing project to point at the mstest framework and stop using NUnit, but VS2010 never recognized the tests, despite the correct creation of the stubs by specflow's custom tool.
So...I added a new Test Project to my solution, moved all of my spec code to that new project, then recompiled, and viola, VS2010 recognizes the tests. I'm sure there is a GUID it is looking for in the XML of the .csproj file or something that tells it to wire up the testing framework, but I didn't dig that far.
Hope this helps someone.
To change your class library project template into a test project, modify the .csproj and add the following line:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
to the first property group element:
<PropertyGroup>
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>