Parent fixture failed in NCrunch - TestContext_proxy cannot be converted - mstest

I'm getting this error in NCrunch when running in MS Test tests:
System.ArgumentException: Object of type
'Microsoft.VisualStudio.TestTools.UnitTesting.TestContext_proxy'
cannot be converted to type
'Microsoft.VisualStudio.TestTools.UnitTesting.TestContext'.
The solution contains many a mixture of MS Test 1 and MS Test 2 projects. All the rest of those project's tests are running normally in NCrunch.
All the MS Test 1 projects are referencing the same MS Test DLL located at C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Checking the source control nothing appears to have changed with the project that's now failing, what could be causing this?

It turns out that the project in question was referencing one of the other test projects, and that referenced project had been changed to use MS Test 2.
The indirect reference to another version of MSTest was meant NCrunch didn't know which version of MSTest to use, which then caused the exception.
The issue took a while to surface because NCrunch was set to only run impacted tests and none of those tests had changed for a while.
A similar issue was discussed in this thread on NCrunch forum:
Your test project is referencing two different versions of MSTest. The
test project directly references MSTest 2017
(Microsoft.VisualStudio.TestPlatform.TestFramework), but indirectly
references an earlier version of MSTest via Voodoo.TestData
(Microsoft.VisualStudio.QualityTools.UnitTestFramework). NCrunch
doesn't know which version to use, so it sets up the runtime
environment for the older version. This results in the TestContext
constructed for the older version of MSTest being passed into an
AssemblyInitialize method targeted towards the newer version, and we
end up with an explosion.

Related

Visual Studio FsUnit test setup - Exception NUnit.Engine.NUnitEngineException

I am using Visual Studio 2013, installed FsUnit 2.2.0, which requires NUnit 3.2.1 and FSharpCore 3.1. I created a separate test project and put a testfixture and test in there. My platform is x64 Win 10. The config is for 'AnyCPU' and 'Debug'. I've tried test settings for x86 and x64. When trying to build and create tests, I get:
------ Discover test started ------
NUnit Adapter 3.2.0.0: Test discovery starting
Exception NUnit.Engine.NUnitEngineException, Exception thrown discovering tests in C:\Users\Dad\Documents\Visual Studio 2013\Projects\...
Cannot run tests in process - a 32 bit process is required.
Exception NUnit.Engine.NUnitEngineException, Exception thrown discovering tests in C:\Users\Dad\Documents\Visual Studio 2013\Projects\...
Cannot run tests in process - a 32 bit process is required.
NUnit Adapter 3.2.0.0: Test discovery complete
========== Discover test finished: 0 found (0:00:00.1230077) ==========
If I change the config for both the test and target projects to 'x86' (instead of AnyCPU) then the error for the base project goes away, but the same thing happens for the test project.
No tests are ever discovered, help please ... and many thanks!
You will need to remove nunit from your solution and install it again with "NUnit3TestAdapter", version 3.0.10 works.
Uninstall any NUnit software in add/remove program and in your solutions. Now using Nuget package manager (tools > NuGet Package Manager > Manage NuGet Packages for solution...) remove any NUnit you have in a solution and install older version (e.g. 3.0.1). Find "NUnit3TestAdapter" and install in version 3.0.10.
I had the same problem with my .NET Core 2.0 project with NUnit 3.9 in Visual Studio 2017 and tests were not showing up in TestExplorer. Was stuck with this for quite some time. None of the solutions suggested in other related questions worked.
Then I figured out from this link that a class library with target .NET Standard does not work. The test project has to target .NET Core. Also, Microsoft.NET.Test.Sdk NuGet is required.
So, the steps are
Make sure that the test project targets .NET Core
Install latest NUnit NuGet (I used 3.9)
Install corresponding NUnitAdapter NuGet (I used NUnit3Adapter)
Install Microsoft.NET.Test.Sdk NuGet
Re-build and your tests will appear in Test Explorer in Visual Studio.
Note: Already added this answer to another .NET Core specific question. Adding here too, as the solution might be helpful in this scenario as well.
There is an error in NUnit 3.2.1 whereby the TestEngine assumes that it can't run a test requiring 32-bit execution in process. The assumption is always valid for NUnit's own runners, but not necessarily when the process is started by some other program. There's an issue filed about this.

Running Jasmine Unit Test within Visual Studio via TFS

Hello I got a question regarding implementing Jasmine unit tests within a specific build of TFS. I found this Tutorial which explains exactly what I want.
But I do not want to use this because I do not want to check in phantomjs.exe, which is a file of +/- 46 MB, so what could I do next?
Does anyone of you know if there is a tutorial available on the web regarding installing it (instead on the TFS) directly on the build server?
It's now possible to reference Chutzpah as a NuGet package:
https://www.nuget.org/packages/Chutzpah
With that package referenced (and Visual Studio 2013 update 2 or later), the tests will be executed during the build. You will need to perform the other steps of adjusting the .runsettings and the test assembly specification to include your test files ...;*.test.js

file not found exception running specflow test with codedui in visualstudio 2013

I've been searching all morning for an answer online to this and I have tried a lot of the suggestions though all solutions seem to be for visual studio 2010 and I am running 2013 premium edition, I can't see anyone with the same problem.
I have premium VS 2013, I installed SpecFlow v1.9 through the extension manager and added the SpecFlow nuget package. I have created a CodedUI test project and added a feature file, some recorded codedui steps and a stepdef file. Nothing is complaining and it all looks like it should work. I have added :
<unitTestProvider name="MsTest"/>
to my App.config so I can run it from the test explorer in visual studio. I eventually want to run the tests via MTM but I will deal with that when I get this to work!
I have built and it is all happy so I go to test explorer and I can see my test so I right click, run the test. It fails with the following error, it does get to my Given step when I debug and falls over trying to open my application.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.TestTools.UITest.WindowsStoreUtility, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
I can not find the reference above when I have looked to add it to my project references, there is a similar one but it breaks some of my other references when I add it. I also had a look at my registry files and the path it is referring to does not exist for me to edit it. From what I have read codedui doesn't work nicely with specflow without a dll file. All references to this fix seem to be for vs 2010 and require that I copy a dll to my specflow source folder. I installed specflow from visual studio so I don't have a program files folder for it so I came to a bit of a sticking point with that solution.
Does anyone have specflow working with visual studio 2013 and a codedui test project? Am I missing a set up step? Or is this genuinely to do with my registry files / references. The error is confusing as I don't see why it is trying to find that reference especially when I can't find that reference anywhere when I try to find it manually. I'd be interested to know if you have had this error and managed to resolve it or if you could explain your set up steps so I can check I did not miss anything.
Thanks!
I believe you might be missing references to some of the required dlls. I just finished testing a test created using a Specflow, codedUI test project on my MS Visual Studio 2013 ultimate and it worked just fine.
Here are the steps which I followed:
Created a class library project.
Added reference to Specflow 1.9 from Extensions and Updates.
Added reference to Specflow CodedUI Attribute Generator (Install-Package SpecFlow.CodedUI -Version 1.0.0.23).
Added references to required libraries required for CodedUI and Test Tools to the project. See below the references I added.
Microsoft.VisualStudio.QualityTools.CodedUITestFramework
Microsoft.VisualStudio.QualityTools.UnitTestFramework
Microsoft.VisualStudio.TestTools.UITest.Common
Microsoft.VisualStudio.TestTools.UITest.Extension
Microsoft.VisualStudio.TestTools.UITest.ExtensionUtilities
Microsoft.VisualStudio.TestTools.UITesting
Added a separate CodedUI project to solution and added references of this project to the class library project.
Create a new Specflow feature file with some test and create step for it in step definition and reference to the function you created or recorded in the CodedUI project in the step definition.
Run the Specflow test from Test Explorer. It should work fine.
Note: The above steps should work just fine if you will create CodedUI project instead of a Class library project.
Mark the test class with the CodedUITest attribute.
I had this exact error message even though I had all the .dll's referenced correctly.
The solution for me was to regenerate the feature files.
(right click project and select "regenerate feature files")
Leaving this answer in case it helps someone in future.
I came across the same issue today, not with specflow but 2013 build controller and agent and codedui tests.
The solution was to install VS2013 Update 5 https://www.visualstudio.com/downloads/download-visual-studio-vs
I had same problem, found the following solution works well:
http://blog.majcica.com/2015/05/07/getting-started-with-specflow-and-codedui/

How do I run MSpec in Visual Studio's test system using Gallio?

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.

xUnit + Gallio + code coverage in Visual Studio 2010

I'm trying to find a way to migrate from mstest to xunit and still benefit from the IDE integration which made me choose mstest in the first place. Gallio seems to accomplish this noble goal, plus it's free (don't want Reshaper or TestDriven.net). But I can't get code coverage to work.
My solution contains of two projects: project SUT (the assembly I need to test) and project SUT.Tests which is a VS test project (this allows Gallio to display xunit tests in VS's Test View). I have code coverage enabled in Local.testSettings for SUT.dll and instrumentation is in place. After the test run completes there is no code coverage. Code Coverage Results window reports: Empty results generated: none of the instrumented binary was used. Look at test run details for any instrumentation problems. Unfortunately the test run details do not contain any "instrumentation problems". I tried unchecking the instrument assemblies in place checkbox and re-running the unit test; same result.
Any idea what's wrong?
My setup:
- Windows 7 x64
- VS 2010 Premium (SP1)
- xUnit 1.8
- Gallio 3.3.1 x64 (installer, not zip)
Apologies for answering my own question:
Turns out Gallio loads SUT.dll from SUT.Tests\Bin\Debug rather than SUT\Bin\Debug. I added this path to code coverage details, selected it instead of the default SUT.dll path and now it works! This is better described at here, towards the end of the post.

Resources