[Feature]: Reconsider the Default Test Timeout Paradigm

[Manuel-Suarez-Abascal]

🚀 Feature Request

The Problem with Default Timeouts

The current approach assumes that:

1. Every test must fail after a specific time, regardless of context:
   This rigid paradigm forces developers to explicitly override the timeout for tests that naturally take longer to run. For example, I have a long test where I must explicitly set test.timeout(90000) just for it to complete, even though nothing has actually gone wrong during execution.

2. Timeouts are indicative of failure:
   A test exceeding 30 seconds doesn’t necessarily mean it has failed. If the test is actively progressing (e.g., elements are loading, assertions are passing), there’s no reason it should be terminated.

3. One-size-fits-all doesn’t fit real-world scenarios:
   The global default timeout can’t account for the wide variety of test cases developers encounter. Long-running tests, large datasets, or external dependencies often make fixed timeouts impractical.

Proposed Solutions:

1. Remove the Global Default Timeout:
   Eliminate the requirement for a hard global timeout altogether, allowing tests to run as long as they are making progress. Developers could still specify custom timeouts if desired, but it would no longer be mandatory.

2. Adopt Progress-Based Timeout Handling:
   Instead of a hard timeout, Playwright could monitor test progress dynamically. A test would only fail if it becomes truly unresponsive (e.g., no DOM changes, no network activity, no assertion attempts) rather than arbitrarily at 30 seconds.

3. Allow Infinite Timeout by Default:
   As a middle ground, provide an "infinite timeout" configuration option for scenarios where developers trust their tests to complete without artificial constraints.

Questions for Discussion:

• What is the rationale behind enforcing a global default timeout in Playwright?
• Would the removal or rethinking of this paradigm simplify workflows for other developers, especially those dealing with complex or long-running tests?

Example

N/A

Motivation

N/A

[Skn0tt]

You're coming with a solution and are putting the problem up for discussion. That's not a good basis for making fundamental, breaking changes. Could you share what problems you're facing in your workflow with the current approach?