Skip to content
| Marketplace
Sign in
Visual Studio Code>Testing>Dotnet Test ProviderNew to Visual Studio Code? Get it now.
Dotnet Test Provider

Dotnet Test Provider

MiJur

|
1 install
| (0) | Free
Discover and run .NET tests in VS Code's built-in Testing view.
Installation
Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.
Copied to clipboard
More Info

Dotnet Test Provider

Run your .NET tests without leaving VS Code.

Dotnet Test Provider brings test discovery, execution, debugging, results, and source navigation into VS Code's built-in Testing view. Open a workspace and get a clear, searchable test tree—without maintaining a separate test command for every project.

Test where you code

  • Discover tests automatically across every .csproj in your workspace.
  • Browse a familiar hierarchy of projects, namespaces, classes, and methods.
  • Run exactly what you need—one method, a class, a namespace, a project, or the whole workspace.
  • Debug supported tests through VSTest test-host attach or native MTP executable launch.
  • See useful failures with runner messages and stack traces in VS Code's Test Results pane.
  • Jump straight to test code from discovered tests and failure messages.
  • Stay up to date while editing with focused refreshes that avoid unnecessary project-wide discovery.
  • Work with coding agents that can discover, run, inspect, and rerun your tests through structured tools.

The extension supports modern SDK-style VSTest projects, Microsoft.Testing.Platform (MTP), compatibility bridge projects, and discovery fallbacks for older .NET Framework projects.

Get started

  1. Install the .NET SDK and make sure dotnet is available on your PATH.
  2. Install Dotnet Test Provider in VS Code.
  3. Open a trusted local workspace containing one or more .NET test projects.
  4. Open the Testing view from the Activity Bar.
  5. Run a test from the tree, or open the Command Palette and choose Dotnet Test Provider: Show Actions.

Discovery starts automatically. If a project has changed substantially, use Dotnet Test Provider: Rebuild Discovered Tests from Scratch from the Command Palette or the Testing view's ... menu.

Built for real .NET workspaces

Dotnet Test Provider chooses the best available path for each project:

Project style Discover Run Debug
SDK-style VSTest Yes Yes Yes
Native Microsoft.Testing.Platform Yes Yes Yes
MTP compatibility bridge Yes Yes No
Classic non-SDK .NET Framework Yes, from a built assembly or source fallback No No

Runner-backed discovery and result files are preferred whenever available. Compatibility fallbacks keep older project shapes visible and clearly report when results are less authoritative.

Debugging requires the Microsoft C# extension or C# Dev Kit. The provider uses the debugger already installed in VS Code and does not bundle one.

Work naturally in the Testing view

Use VS Code's standard test controls to run supported items at any level. The extension keeps the tree and result states synchronized, streams command output to a dedicated channel, and links discovered tests back to their declarations.

Useful commands include:

  • Show Actions — quickly access common test tasks.
  • Run All Tests — run every discovered test project.
  • Run Test Target — pick a project, namespace, class, or method.
  • Debug Test Target — debug a supported target.
  • Go to Test Source — open the selected test declaration.
  • Reveal in Testing View — find a test in the tree.
  • Refresh Discovered Tests — rediscover the workspace.
  • Rebuild Discovered Tests from Scratch — clear cached discovery and rebuild the tree.
  • Show Output — inspect runner output and diagnostics.

Let coding agents run the feedback loop

Dotnet Test Provider exposes structured tools to compatible VS Code chat agents. An agent can:

  • list or search discovered tests;
  • inspect which test projects and capabilities are available;
  • run tests by project, directory, source file, or method;
  • read bounded results and failure details from the latest run; and
  • rerun only the failed or errored tests.

Reference tools such as #runDotnetTests, #findDotnetTests, and #runFailedDotnetTests explicitly in a prompt, or let a compatible agent select them when appropriate. Agent-triggered runs also update the Testing view, so automated and interactive workflows stay in sync.

Configure the runner, not your workflow

Most workspaces need no configuration. When you do need control, the extension supports:

  • extra dotnet test arguments;
  • .runsettings files;
  • VSTest and MTP diagnostic output;
  • preserved TRX artifacts for troubleshooting; and
  • choosing native MTP behavior when supported.

See the configuration reference for setting names, defaults, and an example workspace configuration.

Good to know

  • The extension runs workspace-controlled build and test logic, so it is available only in trusted, local workspaces.
  • Theory and data-driven selections currently run the normalized test method and may execute every data row.
  • Older projects discovered from source may not expose the exact names produced by their test adapter.
  • If C# Dev Kit already provides a better first-party workflow for your project, both extensions can remain installed and you can use the experience that fits that workspace.

Having trouble? The troubleshooting guide covers discovery, execution, debugging, diagnostics, and compatibility fallbacks.

Contributing

Issues and contributions are welcome. For a development build, run npm install, npm run build:helper, and npm run compile, then launch the Run Extension configuration in VS Code. Run npm test before submitting a change.

License

MIT

  • Contact us
  • Jobs
  • Privacy
  • Manage cookies
  • Terms of use
  • Trademarks
© 2026 Microsoft