Dotnet Test Provider
A lightweight .NET test experience for VS Code's built-in Testing view.
Dotnet Test Provider discovers .NET test projects in a trusted local workspace, presents their tests in VS Code's Testing view, and runs them through the project's own test tooling. Run a method while editing, a project before committing, or the entire workspace when you need the full picture—without maintaining custom tasks or leaving the editor.
It is designed for teams that want VS Code's native test UI while working across modern SDK-style projects and older .NET codebases.
What you get
- Automatic discovery of supported test projects when a workspace opens, with manual refresh when needed.
- A navigable test tree organized by project, namespace, class, and method.
- Run controls for the Testing view at the test, class, namespace, project, saved-group, or workspace level, with debugging where the runner supports it.
- Coverage in the Testing view for VSTest projects, including line, branch, and method coverage from the bundled Coverlet collector—no project package change required.
- Results where you work: passed, failed, skipped, errored, and inconclusive outcomes appear in the Testing view with runner messages and stack traces when available.
- Source navigation from tests and failure messages back to C# declarations.
- Run groups for recurring cross-project or focused test selections. Expand a group to inspect its saved targets; use its context menu to rename or delete it, or a saved target's context menu to remove that target.
- Runner-aware execution that reuses builds inside a logical multi-target run when it is safe to do so.
- Structured agent tools for compatible VS Code chat agents: find tests, run stable selections, inspect results, and rerun failures.
The extension uses runner-provided discovery and result artifacts when they are available. Its C# source fallback keeps some older projects visible, but it does not pretend source parsing is equivalent to a test runner.
Supported project styles
| Project style |
Discovery |
Run |
Debug |
| SDK-style VSTest |
Yes |
Yes |
Yes |
| Native Microsoft.Testing.Platform (MTP) |
Yes |
Yes |
When the project exposes direct executable debugging |
| MTP compatibility bridge |
Yes |
Yes |
No |
| Classic non-SDK .NET Framework |
Best-effort: built assembly or C# source fallback |
Not currently supported |
No |
Support is determined per project. The Testing view shows each project's support tier and runner mode so degraded behavior is visible rather than hidden.
Important limits
- A theory or data-driven selection can run the normalized method, which may execute every data row rather than one row.
- Source-only discovery for legacy projects can miss adapter-specific names or structure.
- If artifact or protocol results are unavailable, the extension falls back to console parsing; those results are marked degraded and can be less reliable.
- Debugging requires the Microsoft C# extension or C# Dev Kit and a debugger compatible with the target framework.
- Coverage runs require VSTest. Native MTP and MTP compatibility projects can run tests but cannot currently produce the Coverlet report required by VS Code's Coverage profile.
Get started
- Install a .NET SDK and ensure
dotnet is on PATH.
- Install Dotnet Test Provider in VS Code.
- Open a trusted local workspace containing .NET test projects.
- Open the Testing view. Discovery begins automatically.
- Use the standard Run or Debug controls on a test, scope, project, or saved group.
The extension executes workspace-controlled MSBuild and test logic, so it is unavailable in Restricted Mode and virtual workspaces. If discovery needs a clean reset, run Dotnet Test Provider: Rebuild Discovered Tests from Scratch from the Command Palette or the Testing view menu.
Fit it into your workflow
Most projects work without configuration. Select the Testing view's Coverage profile to run VSTest projects with the bundled Coverlet collector; results appear as line, branch, and method coverage in VS Code. The extension restores the latest coverage automatically when its source files have not changed; use Dotnet Test Provider: Toggle Cached Coverage to disable that behavior.
When projects need customization, configure extra dotnet test arguments, a .runsettings file, VSTest or MTP diagnostics, preserved TRX artifacts, native MTP behavior, and saved test run groups.
Use the editor context menu or Command Palette for Run Tests in Context, Debug Tests in Context, Run Test Target, Debug Test Target, Go to Test Source, and Show Output. The output channel records the runner invocation and explains degraded results, unavailable coverage, or split execution batches.
For compatible VS Code chat agents, reference tools such as #findDotnetTests, #runDotnetTests, #getDotnetTestResults, and #runFailedDotnetTests. Agent runs update the same Testing view as interactive runs. An optional loopback-only MCP server can expose the same tools to external clients; see the configuration reference for its security settings.
Learn more
