-->
Developer Community for Visual Studio Product family. Attachments: Up to 5 attachments (including images) can be used with a maximum of 2.1 GB each and 2.1 GB total. We will write a basic test script, that will open up visual studio code’s official website, and verify if the “Download for Mac” button text is proper or not. Using NUnit.Framework; using NUnit. The code is an add-in to Visual Studio which expands on the add-in I described in my previous article 'How to run all your NUnit tests in a solution in Visual Studio'. Installation Unzip the demo files to a folder somewhere.
Use Test Explorer to run unit tests from Visual Studio or third-party unit test projects. You can also use Test Explorer to group tests into categories, filter the test list, and create, save, and run playlists of tests. You can debug tests and analyze test performance and code coverage.
Visual Studio includes the Microsoft unit testing frameworks for both managed and native code. However, Test Explorer can also run any unit test framework that has implemented a Test Explorer adapter. For more information about installing third-party unit test frameworks, see Install third-party unit test frameworks
Test Explorer can run tests from multiple test projects in a solution and from test classes that are part of the production code projects. Test projects can use different unit test frameworks. When the code under test is written for .NET, the test project can be written in any language that also targets .NET, regardless of the language of the target code. Native C/C++ code projects must be tested by using a C++ unit test framework. For more information, see Write unit tests for C/C++.
Run tests in Test Explorer
When you build the test project, the tests appear in Test Explorer. If Test Explorer is not visible, choose Test on the Visual Studio menu, choose Windows, and then choose Test Explorer.
As you run, write, and rerun your tests, Test Explorer displays the results in default groups of Failed Tests, Passed Tests, Skipped Tests and Not Run Tests. You can change the way Test Explorer groups your tests.
As you run, write, and rerun your tests, the Test Explorer displays the results in a default grouping of Project, Namespace, and Class. You can change the way the Test Explorer groups your tests.
You can perform much of the work of finding, organizing and running tests from the Test Explorer toolbar.
Run tests
You can run all the tests in the solution, all the tests in a group, or a set of tests that you select. Do one of the following:
To run all the tests in a solution, choose Run All.
To run all the tests in a default group, choose Run and then choose the group on the menu.
Select the individual tests that you want to run, open the right-click menu for a selected test and then choose Run Selected Tests.
If individual tests have no dependencies that prevent them from being run in any order, turn on parallel test execution with the toggle button on the toolbar. This can noticeably reduce the time taken to run all the tests.
The pass/fail bar at the top of the Test Explorer window is animated as the tests run. At the conclusion of the test run, the pass/fail bar turns green if all tests passed or turns red if any test failed.
You can run all the tests in the solution, all the tests in a group, or a set of tests that you select. Do one of the following:
To run all the tests in a solution, choose the Run All icon.
To run all the tests in a default group, choose the Run icon and then choose the group on the menu.
Select the individual tests that you want to run, open the right-click menu for a selected test and then choose Run Selected Tests.
If individual tests have no dependencies that prevent them from being run in any order, turn on parallel test execution in the settings menu of the toolbar. This can noticeably reduce the time taken to run all the tests.
Run tests after every build
| Button | Description |
|---|---|
| To run your unit tests after each local build, choose Test on the standard menu, and then choose Run Tests After Build on the Test Explorer toolbar. |
Note
Running unit tests after each build requires Visual Studio 2017 Enterprise or Visual Studio 2019. In Visual Studio 2019 it is included in Community and Professional as well as Enterprise.
To run your unit tests after each local build, open the settings icon in the Test Explorer toolbar and select Run Tests After Build.
View test results
As you run, write, and rerun your tests, Test Explorer displays the results in groups of Failed Tests, Passed Tests, Skipped Tests and Not Run Tests. The details pane at the bottom or side of the Test Explorer displays a summary of the test run.
View test details
To view the details of an individual test, select the test.
The test details pane displays the following information:
The source file name and the line number of the test method.
The status of the test.
The elapsed time that the test method took to run.
If the test fails, the details pane also displays:
The message returned by the unit test framework for the test.
The stack trace at the time the test failed.
View the source code of a test method
To display the source code for a test method in the Visual Studio editor, select the test and then choose Open Test on the right-click menu (Keyboard: F12).
Group and filter the test list
Test Explorer lets you group your tests into predefined categories. Most unit test frameworks that run in Test Explorer let you define your own categories and category/value pairs to group your tests. You can also filter the list of tests by matching strings against test properties.
Group tests in the test list
To change the way that tests are organized, choose the down arrow next to the Group By button and select a new grouping criteria.
Test Explorer lets you group your tests into a hierarchy. The default hierarchy grouping is Project, Namespace, and then Class. To change the way that tests are organized, choose the Group By button and select a new grouping criteria.
You can define your own levels of the hierarchy and group by State and then Class for example by selecting Group By options in your preferred order.
Test Explorer groups
| Group | Description |
|---|---|
| Duration | Groups test by execution time: Fast, Medium, and Slow. |
| Outcome | Groups tests by execution results: Failed Tests, Skipped Tests, Passed Tests. |
| Traits | Groups test by category/value pairs that you define. The syntax to specify trait categories and values is defined by the unit test framework. |
| Project | Groups test by the name of the projects. |
| Group | Description |
|---|---|
| Duration | Groups tests by execution time: Fast, Medium, and Slow. |
| State | Groups tests by execution results: Failed Tests, Skipped Tests, Passed Tests, Not Run |
| Target Framework | Groups tests by the framework their projects target |
| Namespace | Groups tests by the containing namespace. |
| Project | Groups tests by the containing project. |
| Class | Groups tests by the containing class. |
Traits
A trait is usually a category name/value pair, but it can also be a single category. Traits can be assigned to methods that are identified as a test method by the unit test framework. A unit test framework can define trait categories. You can add values to the trait categories to define your own category name/value pairs. The syntax to specify trait categories and values is defined by the unit test framework.
Traits in the Microsoft Unit Testing Framework for Managed Code
In the Microsoft unit test framework for managed apps, you define a trait name/ value pair in a TestPropertyAttribute attribute. The test framework also contains these predefined traits:
| Trait | Description |
|---|---|
| OwnerAttribute | The Owner category is defined by the unit test framework and requires you to provide a string value of the owner. |
| PriorityAttribute | The Priority category is defined by the unit test framework and requires you to provide an integer value of the priority. |
| TestCategoryAttribute | The TestCategory attribute enables you to provide a category without a value. |
| TestPropertyAttribute | The TestProperty attribute enables you to define trait category/value pair. |
Traits in the Microsoft Unit Testing Framework for C++
See How to use the Microsoft Unit Testing Framework for C++.
Create custom playlists
You can create and save a list of tests that you want to run or view as a group. When you select a playlist, the tests in the list are displayed in Test Explorer. You can add a test to more than one playlist, and all tests in your project are available when you choose the default All Tests playlist.
To create a playlist, choose one or more tests in Test Explorer. On the right-click menu, choose Add to Playlist > NewPlaylist. Save the file with the name and location that you specify in the Create New Playlist dialog box.
To add tests to a playlist, choose one or more tests in Test Explorer. On the right-click menu, choose Add to Playlist, and then choose the playlist that you want to add the tests to.
To open a playlist, choose Test > Playlist from the Visual Studio menu, and either choose from the list of recently used playlists, or choose Open Playlist to specify the name and location of the playlist.
If individual tests have no dependencies that prevent them from being run in any order, turn on parallel test execution with the toggle button on the toolbar. This can noticeably reduce the time taken to run all the tests.
You can create and save a list of tests that you want to run or view as a group. When you select a playlist, the tests in the list are displayed in a new Test Explorer tab. You can add a test to more than one playlist.
To create a playlist, choose one or more tests in Test Explorer. On the right-click menu, choose Add to Playlist > New Playlist.
The playlist opens in a new Test Explorer tab. You can use this playlist once and then discard it, or you can click the Save button in the playlist window's toolbar, and then select a name and location to save the playlist.
To create a playlist, choose one or more tests in Test Explorer. Right-click and choose Add to Playlist > New playlist.
To open a playlist, choose the playlist icon in the Visual Studio toolbar and select a previously saved playlist file from the menu.
Test Explorer columns
The groups are also available as columns in Test Explorer, along with Trait, Stack Trace, Error Message, and Fully Qualified Name. Most columns are not visible by default, and you can customize which columns you see and the order in which they appear.
Filter, sort, and rearrange test columns
Columns can be filtered, sorted, and rearranged.
To filter to specific traits, click the filter icon at the top of the Traits column.
To change the order of the columns, click on a column header and drag it left or right.
To sort a column, click on the column header. Not all columns can be sorted. You can also sort by a secondary column by holding the Shift key and clicking on an additional column header.
Search and filter the test list
You can also use Test Explorer search filters to limit the test methods in your projects that you view and run.
When you type a string in the Test Explorer search box and choose Enter, the test list is filtered to display only those tests whose fully qualified names contain the string.
To filter by a different criteria:
Open the drop-down list to the right of the search box.
Choose a new criteria.
Enter the filter value between the quotation marks. If you want to search for an exact match on the string instead of a containing match use an equals sign (=) instead of the colon (:).
Note
Searches are case insensitive and match the specified string to any part of the criteria value.
| Qualifier | Description |
|---|---|
| Trait | Searches both trait category and value for matches. The syntax to specify trait categories and values are defined by the unit test framework. |
| Project | Searches the test project names for matches. |
| Error Message | Searches the user-defined error messages returned by failed asserts for matches. |
| File Path | Searches the fully qualified file name of test source files for matches. |
| Fully Qualified Name | Searches the fully qualified name of test namespaces, classes, and methods for matches. |
| Output | Searches the user-defined error messages that are written to standard output (stdout) or standard error (stderr). The syntax to specify output messages are defined by the unit test framework. |
| Outcome | Searches the Test Explorer category names for matches: Failed Tests, Skipped Tests, Passed Tests. |
| Qualifier | Description |
|---|---|
| State | Searches the Test Explorer category names for matches: Failed Tests, Skipped Tests, Passed Tests. |
| Traits | Searches both trait category and value for matches. The syntax to specify trait categories and values are defined by the unit test framework. |
| Fully Qualified Name | Searches the fully qualified name of test namespaces, classes, and methods for matches. |
| Project | Searches the test project names for matches. |
| Target Framework | Searches the Test Explorer category names for matches: Failed Tests, Skipped Tests, Passed Tests. |
| Namespace | Searches the test namespaces for matches. |
| Class | Searches the test classes names for matches. |
To exclude a subset of the results of a filter, use the following syntax:
For example, FullName:'MyClass' - FullName:'PerfTest' returns all tests that include 'MyClass' in their name, except tests that also include 'PerfTest' in their name.
Debug and analyze unit tests
You can use Test Explorer to start a debugging session for your tests. Stepping through your code with the Visual Studio debugger seamlessly takes you back and forth between the unit tests and the project under test. To start debugging:
In the Visual Studio editor, set a breakpoint in one or more test methods that you want to debug.
Note
Because test methods can run in any order, set breakpoints in all the test methods that you want to debug.
In Test Explorer, select the test methods and then choose Debug Selected Tests on the right-click menu.
For more information, about the debugger, see Debug in Visual Studio.
Diagnose test method performance issues
To diagnose why a test method is taking too much time, select the method in Test Explorer and then choose Profile Selected Test on the right-click menu. See Performance Explorer.
Analyze unit test code coverage
You can determine the amount of product code that is actually being tested by your unit tests by using the Visual Studio code coverage tool that's available in Visual Studio Enterprise edition. You can run code coverage on selected tests or on all tests in a solution.
To run code coverage for test methods in a solution:
Choose Test on the top menu bar and then choose Analyze code coverage.
Choose one of the following commands from the sub-menu:
Selected tests runs the test methods that you have selected in Test Explorer.
All tests runs all the test methods in the solution.
- Right-click in the Test Explorer and select Analyze Code Coverage for Selected tests
The Code Coverage Results window displays the percentage of the blocks of product code that were exercised by line, function, class, namespace and module.
For more information, see Use code coverage to determine how much code is being tested.
Test shortcuts
Tests can be run from the Test Explorer, by right-clicking in the code editor on a test and selecting Run test, or by using the default Test Explorer shortcuts in Visual Studio. Some of the shortcuts are context-based. This means that they run or debug tests based on where your cursor is in the code editor. If your cursor is inside a test method, then that test method runs. If your cursor is at the class level, then all the tests in that class run. This is the same for the namespace level as well.
| Frequent Commands | Keyboard Shortcuts |
|---|---|
| TestExplorer.DebugAllTestsInContext | Ctrl+R, Ctrl+T |
| TestExplorer.RunAllTestsInContext | Ctrl+R, T |
| TestExplorer.RunAllTests | Ctrl+R, A |
| TestExplorer.RepeatLastRun | Ctrl+R, L |
Note
You can't run a test in an abstract class, because tests are only defined in abstract classes and not instantiated. To run tests in abstract classes, create a class that derives from the abstract class.
See also
I've recently been building a test framework for a bit of C# I've been working on. I have NUnit set up and a new project within my workspace to test the component. All works well if I load up my unit tests from Nunit (v2.4), but I've got to the point where it would be really useful to run in debug mode and set some break points.
I've tried the suggestions from several guides which all suggest changing the 'Debug' properties of the test project:
I'm using the console version there, but have tried the calling the GUI as well. Both give me the same error when I try and start debugging:
Is this because I normally load DSP.nunit into the Nunit GUI and that's where the tests are held?
I'm beginning to think the problem may be that VS wants to run it's own test framework and that's why it's failing to find the NUnit tests?
Edit: To those asking about test fixtures, one of my .cs files in the TestDSP project looks roughly like this:
...I'm pretty new to C# and the NUnit test framework so it's entirely possible I've missed some crucial bit of information ;-)
Final Solution: The big problem was the project I'd used. If you pick Other Languages -> Visual C# -> Test -> Test Project ...when you're choosing the project type, Visual Studio will try and use it's own testing framework as far as I can tell. You should pick a normal C# class library project instead and then the instructions in my selected answer will work.
19 Answers
I use the same technique as you are trying Jon, without the /assembly flag, i.e.
Does TestDSP.dll contain all your TestFixtures?
As my test project is not the startup project in the solution, I run my tests by right-clicking on the test project and choosing Debug --> Start New Instance
Patrick McDonaldPatrick McDonaldWhen I need to debug my NUnit tests, I simply attach to the NUnit GUI application nunit-agent.exe using 'Debug|Attach to Process' and run the tests from the GUI. Any breakpoints in my tests (or the code they're testing) are hit. Am I misunderstanding your question, or will that work for you?
Simply remove the line that looks like
from your project file.This line basically tells VS.Net that it's a Test project, thus the 'Cannot start test project'. FYI here the 1st Guid says 'it's a test', the 2nd says 'it's C#'.For information on those Guids: http://www.mztools.com/Articles/2008/MZ2008017.aspx
MikeTheLiarIn addition to the answer provided by @Justin here are some more details for NUnit 2.6.
Using NUnit 2.6 attach to nunit.exe or nunit-console.exe and NOT the agent. The configuration noted by @Justin is slightly different. Below is an example from nunit.exe.config (same for nunit-console.exe.config).
For .NET 4 test project, to get break points to hit, you will have to comment out or remove the v2.0 line as the comment suggests. Once I did that I was able to debug the .NET 4.0 test project.
If you are using NUnit 2.4 or newer you can put the following code in your SetUpFixture class. (You can do this with older versions but you will need to do whatever equivalent that has to the SetUpFixture, or copy it in to the test itself.)
What Debugger.Launch() does is cause the following dialog to show up when you click Run inside NUnit.
You then choose your running instance of visual studio with your project open (the 2nd one in my screenshot) then the debugger will be attached and any breakpoints or exceptions will show up in Visual Studio.
Scott ChamberlainScott ChamberlainIn Nunit 3.0.1 (I'm using VS2013), Open from main menu > Test > Windows > Test Explorer. Then in 'Test explorer', right-click the test case, you might see:
Hope this helps.
QuinnQuinnInstall TestDriven.NET, which is a plugin for Visual Studio
From there you can right click on your unit test assembly and click Run Tests to run the whole suite, right click on a TestFixture class to run just the tests in that class, or right click on a Test method to run just that method.
You also have the option to Test With Debugger, if you need to breakpoint into your tests in debug mode.
Jon LimjapJon LimjapTry NUnitit - a open source Visual Studio Addin for Debugging NUnit Test cases
HomePage - http://nunitit.codeplex.com/
abhilashabhilashNow with pictures:
- Run NUnit gui (Download 2.6.2 from here) then go to
File -> Open Project
Select your test
.dllfrom bin folder (C:......[SolutionFolder][ProjectFolder]binDebugxxxxTests.dll)Go to Visual Studio
Debug -> Attach to process(Attach to process window will open)From the list scroll down and select
nunit-agent.exethen clickAttach
At this point breakpoints in your tests should turn ripe red (from hollow).
Click
RunonNunit Guiand you should get your breakpoint hit...
Hope this saves you some time.
Matas VaitkeviciusMatas VaitkeviciusIf you are able to get the console / or GUI working, but your breakpoints are not being hit, it may be because your app is running a different .NET runtime than NUnit is. Check to see if your nunit-console.exe.config / nunit.exe.config has the runtime specified.(The configurations live in the same directory as the nunit exe's.) Specify the runtime using the startup node:
If project path contains spaces e.g. 'New Project' in path <path>binDebugNew ProjectQuotes.Domain.Tests.dll then enclose the Start Option --> Command Line Arguments project path in double quotes.
I spent a lot of time to figure this out.
MarijnRegarding what Mr. Patrick McDonald said
As my test project is not the startup project in the solution, I run my tests by right-clicking on the test project and choosing Debug --> Start New Instance
I tried to apply for my test class library but got some error regarding the path, so I tried to remove the 'Command Line Arguments', and luckily it worked well and as expected.
It sounds like you are trying to use the wrong library. NUnit can only start if the dll you are using contains TestFixtures.
Visual Studio Debug Unit Test
+1 on TestDriven.Net. I've had the chance to use it a number of times. You can download the personal version for evaluations purposes according the the license at http://testdriven.net/purchase_licenses.aspx.
I got the same error with MSTest. I found that in the Test Output window, some of the tests had duplicate IDs and could not be loaded. I removed all duplicate tests and now I was able to run the tests when i start the project.
There is also an extension now 'Visual NUnit' that will allow you to run the tests from within Visual studio much like the build in test framework handles. Check it out its in the extension manager.
iamkrilliniamkrillinOpen Visual Studio ---> your Project---> Select 'Properties'---> Select 'Debug' --> Select 'Start external program' and set the path of your NUnit there(Eg: Start external program = C:Program FilesNUnit 2.6.2binnunit.exe) ---->Save
After setting this just click Debug
For me solution was to adapt nunit configuration file. To use nunit with 4.5-.Net framework and x64 build option, I had to add one line to startup tag (supported runtime-version).
Afterwards, I could start by right-click on the Testproject Debug -> Start new instance.Before, I needed to again manually attach the project to the process.
My Debug properties were,C:Program Files (x86)NUnit 2.6.4binnunit.exewith argument of the location of the .dll to be tested.
More information: nunit for testing with .NET 4.0
Run Nunit Tests Visual Studio
See if this helps..How to add NUnit in Visual Studio
(RighteousRant)Although personally I don't like this approach.. If you need a debugger while you are test-driving your code, it's a 'smell' in that you do not have enough confidence/know how your code works & need the debugger to tell you that. TDD should free you from needing a debugger if done right. Use 'Attach debugger to NUNit' only for rare cases or when you are wading in someone else's code.