Extend `[Timeout]` to cover hooks, object initializers, and broader scopes

[thomhurst]

Problem

[Timeout] currently only applies to test body execution. Hooks and object initializers have no timeout protection — a misbehaving [Before(HookType.Assembly)] or IAsyncInitializer.InitializeAsync() that hangs will block the entire test run indefinitely.

Goal

Make [Timeout] much more powerful — it should be applicable to:

1. Test body (current behavior)
2. Hooks — [Before] / [After] at all scopes (Test, Class, Assembly, Session, Discovery)
3. Object initializers — IAsyncInitializer.InitializeAsync() implementations
4. Broader scopes — e.g. [Timeout] on an assembly meaning "the entire test run must complete within X"

Design Questions

• How does [Timeout] on a class interact with [Timeout] on individual tests? Is it a total budget for the class, or a default for each test?
• Assembly-level [Timeout] — is it a hard cap on the entire assembly's execution time? What happens to in-flight tests when it fires?
• Hook timeouts — should they inherit from the scope they belong to (e.g. a class-level hook inherits the class timeout), or require explicit configuration?
• Should individual hooks be able to opt out of a scope-level timeout?
• How does this interact with [Retry]? Does each retry get a fresh timeout, or does the timeout cover all retries?
• Object initializer timeouts — should they be separate from the test timeout, or part of it? (Currently data source init runs outside the test timeout)

Notes

• Requires careful design before implementation
• Some aspects may be breaking (changing what [Timeout] on a class means)
• Deferred to v2

[PandrPi]

Hello @thomhurst
I would like to add that Timeout is already a pretty powerful attribute for cancelling async logic; however, the way we need to use it to specify the amount of time after which the cancellation occurs may be defined in a more human-readable way.

In my project, I sometimes have to use relatively large timeouts.
For example, if I need my test to live up to 5 minutes, I need firstly to convert these 5 minutes to milliseconds and then write Timeout(300_000), for a 15-minute timeout it would be Timeout(900_000).
Although these numbers make absolute sense for the code, they make very little sense for humans reading/managing this code.

I propose to implement a second constructor for the TimeoutAttribute class that may look in the following way:

    public TimeoutAttribute(DurationUnit durationUnit, double timeout)
        : this(timeoutInMilliseconds: CalculateTimeoutInMs(durationUnit, timeout)) { }

    /// <summary>
    /// Converts the specified timeout using the specified TimeSpan function into milliseconds
    /// </summary>
    private static int CalculateTimeoutInMs(DurationUnit durationUnit, double timeout)
    {
        return durationUnit switch
        {
            DurationUnit.Day => (int)TimeSpan.FromDays(timeout).TotalMilliseconds,
            DurationUnit.Hour => (int)TimeSpan.FromHours(timeout).TotalMilliseconds,
            DurationUnit.Minute => (int)TimeSpan.FromMinutes(timeout).TotalMilliseconds,
            DurationUnit.Second => (int)TimeSpan.FromSeconds(timeout).TotalMilliseconds,
            DurationUnit.Millisecond => (int)TimeSpan.FromMilliseconds(timeout).TotalMilliseconds,
            DurationUnit.Microsecond => (int)TimeSpan.FromMicroseconds(timeout).TotalMilliseconds,
            var _ => throw new ArgumentOutOfRangeException(nameof(durationUnit), durationUnit,
                "The specified DurationUnit is unsupported!")
        };
    }

For this purpose, I've used the DurationUnit from UnitsNet library, but of course, defining a custom enum like DurationUnit with ~5 values should not be a problem.

In my opinion, this should give the users a more convenient way to use the TimeoutAttribute. I kindly ask you to review this proposal and, if possible, provide feedback.

Best Regards,
Pavlo