Explorer Test
Arleen Jerdee
In version 1.59, VS Code added an official API and UI for running tests, which provides all the functionality of this extension and more.Therefore this extension is now deprecated. I will keep maintaining it so it will remain usable but I don't plan to add any major new features to it.
If you plan to write a new testing extension for VS Code, I recommend you use the native testing API as it's more flexible and has more featuresthan this extension's Test Adapter API. Here's the official guide for the native testing API.
If you're maintaining an extension that uses the Test Adapter API, here is a short guide how to migrate your Test Adapter to the native API.The migration isn't strictly necessary because this extension will remain usable and your users can switch to the native testing UI using thetestExplorer.useNativeTesting setting anyway, but you might find the additional flexibility of the native testing API useful in the future.
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 also use Test Explorer to debug unit tests and, in Visual Studio Enterprise, to analyze code coverage.
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.
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
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.
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.
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.
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.
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.
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.
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.
Starting in Visual Studio 2019 version 16.7, you can choose the Edit button in the toolbar. Check boxes will appear next to your tests showing what tests are included and excluded in the playlist. Edit groups as desired.
You can also check or uncheck the boxes of the parent groups in the hierarchy. This action creates a dynamic playlist that always updates the playlist based on the tests that are in that group. For example, if you place a check mark next to a class, any test added from that class becomes part of this playlist. If you delete a test from that class, it is removed from the playlist. You can learn more about the rules by saving the playlist with the Save button in the toolbar and opening the .playlist file that is created on your disk. This file lists all the rules and individual tests that make up a playlist.
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.
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.
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.
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.
Tests can be run from 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, debug, or profile 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.
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.
Test Explorer can play a sound when a test run completes. There are two sounds: one sound to indicate the test run succeeded with all passing tests, and a second sound to indicate the test run completed with at least one failing test. You can set up these sounds in the default Windows 11 sound dialog. This feature is available starting in Visual Studio 2019 Update 16.9 Preview 3.
I created an assembly called Exitus.Tests, and added a few unit tests. However, do to some issues with Nuget, that I could not solve, I made another project called Exitus.UnitTests and removed the once file I had in the old project (including changing the namespace).
System.InvalidOperationException: The following TestContainer was not found 'C:\Users\xxx\Source\Repositories\Expire\Exitus.Tests\bin\Debug\Exitus.Tests.dll' at Microsoft.VisualStudio.TestWindow.Client.TestContainer.TestContainerProvider.d__46.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.TestWindow.Controller.TestContainerConfigurationQueryByTestsBase.d__6.MoveNext() (...)
The stack trace is a lot longer, but the curious thing is the second line, stating that it could not find the test container at \Exitus.Tests\bin\Debug\Exitus.Tests.dll. This is the name of the old test project, which I removed and deleted. I have searched my entire project for the term Exitus.Tests and it returns no results.