Add TaskRunTestMethodAttribute with integrated timeout for non-cooperative cancellation

[Copilot]

Introduces a specialized test method attribute that wraps test execution in Task.Run with integrated timeout handling for non-cooperative cancellation scenarios. This provides an alternative to the global UseCooperativeCancellation setting by moving timeout logic into the attribute itself.

Changes

New Attribute

• TaskRunTestMethodAttribute(timeout) - Wraps test invocation in Task.Run with timeout parameter (in milliseconds)
• Implements non-cooperative timeout: stops awaiting after timeout, task continues in background
• Handles STA threading requirements (creates STA thread on Windows when needed, otherwise uses thread pool)
• Supports composition via constructor accepting TestMethodAttribute (follows STATestMethodAttribute pattern)
• Timeout logic is self-contained in the attribute, no dependency on adapter

Analyzer (MSTEST0045)

• Suppresses diagnostic when TaskRunTestMethodAttribute is present
• Updated resources to suggest both CooperativeCancellation = true and [TaskRunTestMethod(n)]
• Added symbol comparison logic with inheritance support

Code Fix

• Provides two options:
  1. Set CooperativeCancellation = true on [Timeout] attribute
  2. Replace [TestMethod] and [Timeout(n)] with [TaskRunTestMethod(n)]
• Extracts timeout value from [Timeout] attribute and passes to [TaskRunTestMethod]
• Removes [Timeout] attribute when applying TaskRunTestMethod fix
• New resource string: UseTaskRunTestMethodFix

API Surface

• Added to PublicAPI.Unshipped.txt with timeout parameter and Timeout property
• Added to WellKnownTypeNames.cs

Usage

[TestClass]
public class MyTests
{
    // Non-cooperative timeout - stops awaiting after 5 seconds, task continues in background
    [TaskRunTestMethod(5000)]
    public async Task TestWithNonCooperativeTimeout()
    {
        await SomeOperation();
    }
    
    // For cooperative timeout where test is awaited until completion:
    [TestMethod]
    [Timeout(5000, CooperativeCancellation = true)]
    public async Task TestWithCooperativeTimeout(CancellationToken ct)
    {
        await SomeOperation(ct);  // Observes cancellation cooperatively
    }
}

Key Differences

• TaskRunTestMethod: Non-cooperative timeout. Test is marked as timed out and runner stops awaiting, but task may continue running in background. Useful when you don't want to block but accept potential dangling tasks.
• Timeout with CooperativeCancellation = true: Cooperative timeout. Test is awaited until completion. Prevents dangling tasks if test observes cancellation properly.

Users can now explicitly choose the timeout behavior per-test rather than relying on global settings.

• Fixes Add TaskRunTestMethod #5932

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add TaskRunTestMethod</issue_title>
<issue_description>## Summary

Add a specialized TestMethodAttribute to run the user code as part of a Task.Run allowing to stop wathching the task in case of timeout.

Background and Motivation

As of today, the TestMethod and derived attributes behavior is changing based on whether or not UseCooperativeCancellation is set to true. This is done to allow some back-compat where MSTest doesn't block if the user doesn't handle the cancellation token correctly in case of a timeout. But this is causing many danling tasks #2433 which can lead to confusions or even errors because the test method is still running.

As part of the effort to simplify the core MSTEst logic and to move each responsability to the right location, it seems more logical that this feature is moved down to a specialized test method attribute.

Proposed Feature

• Introduce a new attribute to handle the logic on timeout
• Update the diagnostic recommandign to use cooperative cancellation
• Update related codefix.

Alternative Designs

None</issue_description>

Comments on the Issue (you are @copilot in this section)

@Youssef1313 With the current design of `TestMethodAttribute` where `Execute` only accepts `ITestMethod`, it might not be easy for us to flow the cancellation token to `TestMethodAttribute`.

I think it might be best to take a breaking change in v4 to change the ExecuteAsync signature to take some type which is easy to extend and add properties to as necessary.</comment_new>
<comment_new>@Youssef1313
Or, we can add TestContext/CancellationToken to ITestMethod. In fact, our concrete implementation of ITestMethod (TestMethodInfo) has ITestContext. But whether or not it should really belong there is something I'm not sure about, but I feel it doesn't belong there. Other than this small design concern around TestMethodAttribute, this makes perfect sense to me. Currently, the adapter is really concerned about too much stuff that should be taken out.</comment_new>

• Fixes Add TaskRunTestMethod #5932

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Youssef1313]

Don't we need a timeout parameter?

[Copilot]

Added timeout parameter to the constructor. The attribute now accepts TaskRunTestMethod(5000) where 5000 is the timeout in milliseconds. Commit: ac903bb

[Youssef1313]

I think what we would need is [TaskRunTestMethod(5000)]. The whole implementation then is in the attribute, and the adapter knows nothing about this.

[Evangelink]

I have done a quick look through the app and we will need the adapter to inject a service so we can know about the timeout defined in run settings or testconfig.json. I have the feeling that to keep parity with the rest we will probably need to keep the Timeout attribute too.

[Youssef1313]

Couldn't we add the timeout value on ITestMethod?

Well, the ITestMethod implementation already has the timeout info, it's just not part of the interface.

[Evangelink]

@copilot please handle the timeout

[Copilot]

Implemented [TaskRunTestMethod(5000)] with timeout handling in the attribute itself. The code fix now extracts the timeout value from [Timeout] and creates [TaskRunTestMethod(timeout)], removing the need for a separate Timeout attribute. Commit: ac903bb

[Youssef1313]

If STA with specified in runsettings, we are breaking it here because threadpool threads are not STA and we need to create our own custom thread.

I'm also not sure if we should simply just always create our custom thread and never use the threadpool here.

[Copilot]

Added STA thread handling. The attribute now checks if the current thread is STA and creates a dedicated STA thread when needed (on Windows platforms), otherwise uses Task.Run with the thread pool. Commit: ac903bb

[Evangelink]

I'll need to do some extra prompting because TaskRunTestMethod doesn't prevent dangling tasks. Only cooperative mode on the Test method does. Instead this one is supposed to help with the logic of non cooperative cancellation.

[Copilot]

I'll need to do some extra prompting because TaskRunTestMethod doesn't prevent dangling tasks. Only cooperative mode on the Test method does. Instead this one is supposed to help with the logic of non...

Updated the documentation to clarify that TaskRunTestMethod provides non-cooperative timeout handling (stops awaiting but task continues in background). For cooperative mode that prevents dangling tasks, users should use [Timeout(n, CooperativeCancellation = true)] instead. Commit: ac903bb

[Youssef1313]

Is this pattern leaving the timer of Task.Delay running in the background?