Is there an official Visual Studio test project template for NUnit? If not, what might one look like?
There is no official one. Just start a class library project and import the nUnit assemblies to it.
There are plenty of template how to articles around though - here is one.
We can use this official Template for Unit Testing as well.
Somebody on Github made a template: https://github.com/orangutanboy/NUnitTestFixtureTemplate
When creating a MVC application you have the option for creating a unit test project. Does not give examples but provides a framework.
There is no official template for NUnit exists in visual studio.you have to explaicitly download it. But it has general unit test framework.
you need to download Nunit framework using either nuget package.
Select Tool menu -> Library package manager ->manage nuget package for solution
or
Select Tool menu -> Library package manager ->package manager for console.
Add the reference in existing unit test project and remove the existing unit test namespace from it.
Related
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I have created a project using specflow, so I have a new feature file saved as a class library project, when I try and run the project I get the error: 'A project with an Output Type of Class Library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project'
I think it's an error with the way I have added the n-unit and specflow references to the project. I have noticed I could install specflow via NuGet packages or extensions and updates. So what the difference between adding packages in these two ways?
They are two different things.
the Specflow extension extends the visual studio ide to support specflow. Specifically:
it adds syntax highlighting support for gherkin syntax
it allows the tests to be generated from .feature files
it adds the file templates to the file types so you can add new feature files/step bindings
it adds the additional context menu options to allow steps to be generated and the navigation between steps in the feature file and steps in the code.
it allows integration with the visual studio unit test windows
and probably a few more things that I've neglected to mention. Without this writing specflow tests in visual studio would be more difficult and the generation of the unit test cases themselves would be not be done.
the nuget package allows an individual project to use specflow. This adds the necessary references to the project so that you can consume the types which specflow uses. without these being referenced the projects which try and use specflow would not compile.
As for your issue, this is not related to specflow in any way. A project which builds a dll cannot be started, it needs something to be hosted in in order to be used any project which is a library will give this error if you set it as the startup project regardless of if you use specflow or not.
I'm trying to make a very simple Xamarin.Forms test application to explore some features of the System.Data.SQLite package (namely encryption). However, I can't seem to get Visual Studio 2012 to add a reference to the package to the project.
Here are the steps I am taking:
Created a new Xamarin.Forms Portable blank app.
Right-click on TestApp (core project) and select Manage NuGet Packages
Search for "sqlite"
Install the "System.Data.SQLite (x86/x64)" package. (This package is version 1.0.97.0 and it is described as "the official SQLite database engine for both x86 and x64 along with the ADO.NET provider.")
According to NuGet, the package was successfully installed.
However, I cannot see the reference added under my project's "References" folder, and I also cannot write "using System.Data.SQLite" without errors ("cannot resolve symbol 'Data'"). Does anyone have any idea why this is happening?
On a side note, I can follow the exact same process described above except instead of creating a Xamarin.Forms Portable blank app, I choose a regular C# console app. This allows me to install the NuGet package fine and it shows up in references as expected.
Posting an update to share what I've learned.
So as Jason sort of alluded to in his answer, the reason I was not able to reference the package in my Xamarin.Forms project is because Xamarin.Forms is, by definition, a PCL project. It's meant to work on all platforms. The package I was referring to in my question is not a PCL, which means that anything in the package that is platform dependent is inaccessable (which is basically the entire package). The SQLite.Net-PCL package is basically the same thing as System.Data.SQLite, but in PCL form, which means it is compatible for use in a Xamarin.Forms project.
Following this logic, it makes sense that I was able to access System.Data.SQLite from a console project, since a console project is not a PCL project and it targets a specific platform.
For PCL projects, use SQLite.Net-PCL.
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 want to add MOQ .net library to a .NET 4.0 project. I get an error message that I should convert the project to something smaller than 4.0. I need to use .NET 4.0 also because of other project dependencies.
How can I make MOQ work with a .NET 4.0 project in VS2010 ?
Make sure you have NuGet package manager installed (Tools/Extension Manager).
Right click on Solution Explorer/References, choose Manage NuGet Packages.
Type Moq in the search box.
Install and enjoy.
The latest version from Google Code (http://code.google.com/p/moq/), works in a .Net 4.0 project. I would just download the dll again.
Here is the download link: http://code.google.com/p/moq/downloads/detail?name=Moq.4.0.10827.Final.zip
The zip file at that location contains a .Net 4 folder. Use the dll : Moq.dll from the NET40 folder and everthing will work fine. Just do a normal Add Reference on the project.
I would check the version number and the Runtime veseion of the assembly you are trying to use. It should say:
Runtime Version: v4.0.20926
Version: 4.0.10827.0
For the sake of completeness, it may be worth pointing out that it is also possible to use the Visual Studio command line package manager tool:
1) Open the console in VS
View >> Other Windows >> Package Manager Console
2) Install Moq
Type Install-Package Moq at the prompt
Note: If your tests are in a separate project, make sure that you select that project in the project dropdown.
This will install the latest package available in NuGet, which should address your compatibility issue. See http://nuget.org/packages/moq.
Watch out that you're using .NET 4, rather than the .NET 4 Client Profile as your Target Framework. I had the same issue and that was the cause for me.