I am integrating our internal project tool with Visual studio

A publicly documented placement point for inserting a command directly below Run in Test Explorer—and an API for obtaining its selected tests—could not be verified, so implement Run with XXX monitor in a documented menu location unless Microsoft confirms a supported Test Explorer extension point.

Supported implementation

Create a Visual Studio extension command and place it under Extensions or Tools. The newer VisualStudio.Extensibility model supports those known placements; other locations require the documented GUID and ID of an existing VSCT group. Priority only controls ordering among commands in the same group.^1^

A minimal command is:

using Microsoft.VisualStudio.Extensibility;
using Microsoft.VisualStudio.Extensibility.Commands;
using Microsoft.VisualStudio.Extensibility.Shell;
using System.Diagnostics;

[VisualStudioContribution]
public class RunWithMonitorCommand : Command
{
    public RunWithMonitorCommand(VisualStudioExtensibility extensibility)
        : base(extensibility) { }

    public override CommandConfiguration CommandConfiguration =>
        new("%RunWithMonitor.DisplayName%")
        {
            Placements = [CommandPlacement.KnownPlacements.ExtensionsMenu]
        };

    public override Task ExecuteCommandAsync(
        IClientContext context, CancellationToken cancellationToken)
    {
        Process.Start(new ProcessStartInfo("xxx-monitor.exe")
            { UseShellExecute = true });
        return Task.CompletedTask;
    }
}

Replace the Process.Start body with application-specific orchestration that:

1. Starts XXX monitor.
2. Runs the appropriate test runner with a user-supplied test filter.
3. Stops the monitor in a finally block.
4. Reports the test runner’s exit code.

This route does not automatically receive the tests selected in Test Explorer. The current documentation describes Test Explorer’s built-in right-click operations, but does not document an extension-facing selected-test command target or selection API.^2^

Why a VSCT entry cannot yet be specified

Traditional in-process VSSDK extensions define commands, groups, and menu placement in a .vsct file.^3^ A typical custom command requires:

• A Button for the command.
• A Group that hosts it.
• A Parent or CommandPlacement targeting a documented menu/group GUID and ID.
• A priority controlling its relative position within that group.^4^

The published Visual Studio menu/group ID list does not provide a Test Explorer selected-test context-menu group in the material available here.^5^ Consequently, there is no documented GUID/ID that can safely be supplied for this exact placement.

Do not substitute IDs discovered by reverse engineering or command-inspection tools for a documented extension point. They may be implementation details and can change between Visual Studio updates. The inference is that this exact location is undocumented or unsupported; only Microsoft can confirm whether a private placement has a supported public equivalent.

If exact placement is mandatory

Open a Visual Studio extensibility support request or feature request and ask Microsoft to confirm both:

1. A supported VSCT GUID/group ID for the Test Explorer selected-test context menu.
2. A supported API that returns the selected test identities to the invoked command.

Both are required. A menu placement alone would display the command but would not provide enough documented information to run the selected tests.

If Microsoft supplies a supported parent, use either:

• CommandPlacement.VsctParent(parentGuid, parentId, priority) in the newer extensibility model, or
• a .vsct Parent/CommandPlacement in a traditional VSPackage.

Keep these two extension models separate rather than combining their project setup or command registration.

Conditional alternative

If XXX monitor must wrap every run rather than only an explicitly selected command, integration with the particular test framework, adapter, or external test runner may be more appropriate. That depends on whether the monitor supports setup/teardown hooks and whether the framework exposes run-level lifecycle integration; the available documentation does not establish those details for your internal tool.

References

1. Add Visual Studio commands
2. Run Unit Tests with Test Explorer - Visual Studio (Windows)
3. Extend menus and commands
4. Author .vsct files
5. GUIDs and IDs of Visual Studio menus