[Feature]: Add `repeat` option to `test()` config

🚀 Feature Request

Proposed API

test('should repeat 20 times', {
  repeat: 20,
}, async ({ page }) => {
  // ...
});

The test would execute 20 consecutive times regardless of pass/fail status.

---

Use Cases

• Investigating flaky tests
• Stress-testing newly added tests
• Verifying test stability before enabling CI gates
• Reproducing intermittent failures locally
• Running targeted stability checks without repeating the entire suite

---

Why Existing Features Are Insufficient

--retries

• Only reruns failed tests
• Does not help proactively validate stability

--repeat-each

• Repeats every test in the suite
• Significantly increases execution time when only a few tests need additional validation

This proposal provides a targeted, per-test alternative.

---

Why --repeat-each=20 with test.only() Doesn't Satisfy This Need

As noted in @dgozman's comment, combining --repeat-each with test.only() is not equivalent — test.only() skips all other tests, meaning it cannot run alongside the full suite in a normal run.

The repeat option would enable environment-driven control. For example, with repeat: process.env.REPEAT:

• Scheduled nightly run — set REPEAT=1 (standard single execution alongside the full suite)
• Stress test run — set REPEAT=10 (repeated validation for targeted tests only, while the rest of the suite still runs normally)

This makes the feature composable with existing CI workflows without disrupting the broader test suite.

Example

test('should repeat 20 times', {
  repeat: 20,
}, async ({ page }) => {
  // ...
});

Motivation

Playwright currently provides:

• --retries=N to rerun failed tests
• --repeat-each=N to rerun every test multiple times

However, there is no built-in mechanism to repeatedly execute only a subset of tests.

This becomes useful when investigating flaky tests or validating the stability of a newly added test. In these scenarios, running the entire suite repeatedly is expensive and time-consuming, while --retries only triggers after a failure occurs.

Start by tracing how the test() configuration is represented and how the existing --repeat-each option schedules executions. Compare the proposed repeat behavior with retries, then verify that a per-test repeat count runs consecutively regardless of pass or fail while the rest of the suite runs normally.