I have done this a couple of times before, but it's not working today. Am I missing something?
I want to configure Specflow from the scract, using NUnit and to execute inside Visual Studio.
I've seen many tutorials but they are not working to me :P. I'm trying to use the latest versions.
These are the steps I'm doing on Visual Studio 2017:
Create a test project (.NET Framework)
Install Specflow plugin for Visual Studio (Tools > Extensions and Updates)
Delete reference of MSTests from the nuget packages.
Install SpecFlow 3.0.199
Install NUnit 3.11
Install SpecRun.Runner 3.0.284
After creating a default feature file and generate its steps, when I compile the solution I get this error on CalculatorFeature.feature.cs (the generated file):
It's like those configurations are not compatible. What's going on?
If you have another step by step list, let me know how to configure Specflow with NUnit to run on Visual Studio 2017, please.
For SpecFlow 3 you have to use the MSBuild generation.
To this, follow these two steps:
Add the NuGet package SpecFlow.Tools.MsBuild.Generation with the same version as SpecFlow to your project
Remove all SpecFlowSingleFileGenerator custom tool entries from your feature files.
From https://specflow.org/2019/generating-code-behind-files-using-msbuild/
Background what is happening:
The VS Extension has sometimes problems to find the used SpecFlow version. In that case, it falls back to the SpecFlow version shipped with the extension (which is really old). This version is generating code with now not existing NUnit attributes.
TestFixtureSetUp and TestFixtureTearDown attributes were deprecated for quite some time and were finally removed. They are replaced by OneTimeSetUp and OneTimeTearDown.
Your choices are probably...
Go back to an NUnit version that supports the old attributes.
Get a version of SpecFlow that uses the new attributes.
Find a way to configure SpecFlow and tell it to use the new attributes. Sorry, but this option, which is no doubt the best, is out of my wheelhouse.
Related
I am trying to execute NUnit tests on a legacy project in Visual Studio 2022 professional. Migrating from NUnit 2 to NUnit 3 is not yet an option, and part of the team works with Visual Studio 2019. The problem I am facing is that the tests are not executed by VS 2022, without any error message on the attempt.
The test explorer displays the following after executing the test (and the console output finishes with a successful build):
The NuGet Package manager had NUnit 2.6.1 already installed. I additionally installed the packets NUnit.Extension.NUnitV2Driver and NUnit.Extension.NUnitV2ResultWriter. A test adapter seems only available for NUnit3 (NUnit3TestAdapter, which I also installed). I enabled all the packages for the individual project as was commented in this question. Is there anything else to install/configure that I could be missing to make this work?
Just a few suggested approaches...
The NUnit3TestAdapter, as the name indicates, is designed for NUnit 3. While it is able to run NUnit3 tests by use of the NUnitV2Driver extension, I don't think that will work under Visual Studio just by installing the package. You could experiment by modifying the .addins file installed along with the the adapter, but I can't give you precise instructions as I haven't tried it.
BTW, the V2 driver extension produces output in V3 format, which is probably what you want for use under Visual Studio. The V2 result writer is only needed if you have a reason to want an output file in V2 format.
I think your best bet may be to try using the last release of the NUnitTestAdapter (i.e. without '3' in the name), which only works with NUnit V2. If it will load under VS2022, it should do exactly what you want. In that case, you should stop loading the two extensions, which the V2 runner doesn't support.
I have an xUnit unit testing project. All was working fine in .NET 5.
In Visual Studio 2022, I changed the .NET Version in the csproj to .NET 6 as shown below.
Following this, the tests build but no longer run.
There is no info in the output window. The Test Explorer just says it wont run the tests, with 'unexpected error detected'.
What should I do to fix this?
I created a new project and compared the csproj file with my old project. There were a couple of differences
First, I needed to add the nuget package for Microsoft.NET.Test.Sdk (in my case, version 16.11.0). This seemed to fix it.
I also noticed a couple of properties in the first PropertyGroup that I was missing. I added those too. However, just adding Microsoft.NET.Test.Sdk fixed it for me.
In my case I was changing from NUnit to XUnit and also needed to add the xunit.runner.visualstudio nuget package
I'm currently part of a team that is working on a rather large Typescript project in Visual Studio. As time has gone by and different versions of the project has been released, we've run into a snag when it comes to the versioning of Typescript installed together with Visual Studio.
Scenario:
v 1.1.0 of product released, built on TypeScript 1.8
v 1.2.0 of product released, built on TypeScript 2.1
A bug from customer X is reported for the 1.1.0 version, and the team will start working on a fix.
Problem:
Visual Studio is currently configured to use the latest version of TypeScript (2.1 in this case), so the code from v 1.1.0 does not compile.
Yes, I can manually change typescript versions in the project file and move around on tsc.exe to make this work. Typescript is installed globally as well, but for some reason, they decided that Visual Studio will install the compiler in its own folder instead of acessing the globally installed one.
Hoping someone else has run into this problem, and have a better approach to this.
This was solved by adding the following parameter to my .csproj file:
<TypeScriptCompileBlocked>True</TypeScriptCompiledBlocked>
Ended up running a grunt watch task, using the globally installed TypeScript compiler to compile the project.
Fetched from the official TypeScript docs
If you are using a different build tool to build your project (e.g. gulp, grunt , etc.) and VS for the development and debugging experience, set true in your project. This should give you all the editing support, but not the build when you hit F5.
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/
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.