Autorun is a modality of a profile, it's not its own type of profile. I would recommend letting the user configure their mode/trigger under the "configure test profile" action.

I tried using 'testing.startContinuousRun' and passing a profile to it, but it still pops up the profile chooser instead of executing the autoRun.

That's present if there are multiple available continuous runs. I could make a change to allow passing a profile and/or TestItem to this command

@connor4312, thanks for the reply.

Autorun is a modality of a profile, it's not its own type of profile. I would recommend letting the user configure their mode/trigger under the "configure test profile" action.

To ensure I fully understand your suggestion, are you advising against creating separate autoRun profiles and recommending we enable the supportsContinuousRun option within the regular run profile instead, correct?

Additionally, I am curious why "coverage" isn't treated as just another "modality" like supportsContinuousRun, rather than as a separate profile. The coverage button behaves differently compared to the run/debug buttons; it lacks a dropdown menu for selecting a coverage profile, setting a default, or configuring options. Is this by design? How are users expected to choose which coverage profile to run or adjust its configuration? This question isn't directly related to the current ticket, but your insights would help us better understand the conceptual design of the system.

That's present if there are multiple available continuous runs. I could make a change to allow passing a profile and/or TestItem to this command.

That would be great. 👍

@connor4312, notice a new issue with autoRun, adding to the original post:

3. In a multi-root project with multiple TestControllers and autoRun profiles, there is currently no method to view the status of an individual autoRun profile or to stop one specifically. The autoRun status button attempts to stop all autoRuns collectively and indicates a 'running' status if any of the profiles are active.

thoughts?

@connor4312, I'm encountering another issue related to the display of the continuous run button at the test item level, which might be connected to #178973:

In our configuration, initiating auto-run for each test item isn't practical. Ideally, I'd like to disable this for all items except possibly the root item. Initially, I assumed these settings were driven by runTag, similar to other TestItem buttons, so I attempted to create a new auto-run profile with a different runTag. Unfortunately, this method was ineffective as the buttons were automatically applied to all items once any auto-run profile was created. This underscores the need for more granular control.

Moreover, I'm uncertain if using a profile tag to manage the TestItem's continuous buttons is advisable, particularly since you've indicated that auto-run is not a separate profile but rather a modality of an existing profile. Under this assumption, we would have a single run profile marked continuous=true that is applicable to all test items via matching tags. Therefore, it seems we might need a different mechanism to specify continuous run eligibility for each TestItem...?

I've added this issue to the original post above (4). As the issue list grows, I'm starting to worry if I have misunderstood the continuous run design. Your insights would be highly valuable and greatly appreciated.

@connor4312, is there any traction on passing a profile and/or TestItem to the 'testing.startContinuousRun' command? If not, are you open for a PR?

To ensure I fully understand your suggestion, are you advising against creating separate autoRun profiles and recommending we enable the supportsContinuousRun option within the regular run profile instead, correct?

Yes, exactly. I'm curious whether the two modes of auto-run can be served by a configuration property that would let the user pick they want in user/workspace settings.

Additionally, I am curious why "coverage" isn't treated as just another "modality" like supportsContinuousRun, rather than as a separate profile. The coverage button behaves differently compared to the run/debug buttons; it lacks a dropdown menu for selecting a coverage profile, setting a default, or configuring options. Is this by design? How are users expected to choose which coverage profile to run or adjust its configuration? This question isn't directly related to the current ticket, but your insights would help us better understand the conceptual design of the system.

Technically someone could debug with coverage (in some systems) but these are rather distinct actions a user tends to take. Most editors (e.g IntelliJ, Visual Studio, Eclipse) offer these as distinct actions, so that's the pattern I followed here. I think XCode is the only one that allows enabling coverage in arbitrary configurations. Though technically any test run type can emit coverage information in VS Code, we don't enforce either way, so an extension could have some user configuration to request this.

In a multi-root project with multiple TestControllers and autoRun profiles, there is currently no method to view the status of an individual autoRun profile or to stop one specifically. The autoRun status button attempts to stop all autoRuns collectively and indicates a 'running' status if any of the profiles are active.
thoughts?

I will fix this.

I'm encountering another issue related to the display of the continuous run button at the test item level, which might be connected to

I think that's covered by #228978 and it should now work for you since the October release. Please let me know if not.

is there any traction on passing a profile and/or TestItem to the 'testing.startContinuousRun' command? If not, are you open for a PR?

Will add that today/tomorrow

Commands are in the next Insiders, example usage:

vscode.commands.registerCommand('test-provider-sample.startCR',  () => {
	const testItem = getOrCreateFile(ctrl, vscode.window.activeTextEditor!.document.uri).file;
	vscode.commands.executeCommand('vscode.startContinuousTestRun', runProfile, [testItem]);
});
vscode.commands.registerCommand('test-provider-sample.stopCR',  () => {
	const testItem = getOrCreateFile(ctrl, vscode.window.activeTextEditor!.document.uri).file;
	vscode.commands.executeCommand('vscode.stopContinuousTestRun', [testItem]);
});