[Feature]: Re-run Up To Step, Re-run From Step, and Skip Step Using UI

[jacklaing-sage]

🚀 Feature Request

Playwright UI Mode already provides an excellent way to inspect test execution through the action timeline and trace view. However, when working with long-running end-to-end tests, it can be time-consuming to repeatedly rerun the entire test to reach a specific point of interest.

It would be useful if individual steps within the UI could expose additional execution actions such as:

• Run up to this step
• Run from this step
• Skip this step

Example

Run Up To Step

Allows a user to select any step within the action timeline and run the test until that step is reached.

Example:

1. Test fails on step 87.
2. User selects step 87.
3. Clicks Run up to this step.
4. Playwright executes the test until step 87 is reached.

This would be particularly useful for long authentication, setup, onboarding, or payment flows where developers repeatedly need to reach the same part of a test.

Run From Step

Allows a user to re-execute a test from a selected step rather than repeatedly rerunning the entire test.

Example:

1. Test fails on step 87.
2. The issue is understood or fixed.
3. User selects step 87.
4. Clicks Run from this step.
5. Playwright executes from the selected point onward.

The implementation details are intentionally left open, but the goal is to reduce the cost of repeatedly replaying lengthy workflows when investigating failures.

Skip Step

Allows a user to bypass a step and continue execution from the next step.

This is particularly useful when investigating failures caused by known environmental or dependency issues.

Example:

A test validates that a webhook has been received:

await expect(webhookReceived).toBeTruthy();

Sometimes the webhook may not arrive due to a known issue or temporary external dependency problem. In this scenario, the entire test stops even though a developer may wish to continue exploring the remaining behaviour of the application.

By selecting the failed step and choosing Skip Step, Playwright would:

• Mark the step as skipped for the current run.
• Continue execution from the next step.
• Leave the test source unchanged.

Motivation

Motivation

Many modern Playwright suites contain:

• Authentication flows
• Payment journeys
• Third-party integrations
• Webhook validation
• Long setup and provisioning processes
• Extensive test data creation

When failures occur deep into execution, developers often spend more time replaying the same setup steps than investigating the actual problem.

These execution options would significantly improve productivity within UI Mode and make it easier to iterate on failures without constantly restarting entire workflows.

Example Workflow

Current:

1. Test fails on step 87.
2. Investigate failure.
3. Re-run test.
4. Wait for steps 1-86 to execute again.
5. Continue investigation.

Proposed:

1. Test fails on step 87.
2. Right-click the step.
3. Select:
4. Run up to this step OR Run from this step OR Skip step
5. Continue working immediately.

This would be especially valuable for large end-to-end suites where individual failures can occur many minutes into execution and where external dependencies (such as webhooks, downstream services, or third-party integrations) can occasionally fail in ways that are already known and understood.

[dgozman]

We discussed this, and think something like this should be done, but in the cli instead of UI mode.

[jacklaing-sage]

Thanks for the response.

Just out of curiosity, what's the reasoning behind preferring a CLI implementation over UI Mode?

My thinking was that this feels like something that would fit quite naturally into the existing action timeline that's already exposed in the UI. For example, selecting or right-clicking a step could present options such as:

Run up to this step
Run from this step
Skip this step

The reason I initially thought of UI Mode is that this is where I personally find myself wanting this functionality most often. Most of our day-to-day investigation and debugging happens there, whereas CLI execution is typically automated or used in CI/CD pipelines where these kinds of interactions aren't really needed.

Also, the docs currently say:

"We highly recommend running your tests with UI Mode for a better developer experience where you can easily walk through each step of your test and visually see what was happening before, during and after each step."

so UI Mode felt like a natural fit for step-level actions.

I'm mostly just interested in understanding the reasoning behind the CLI-first approach, as I suspect a lot of users would end up using this functionality from within UI Mode if it were to be provided.

Personally, that's where I feel the feature would provide the most value, but maybe I'm missing something or not considering a constraint that makes the CLI a better fit. I'd be genuinely interested to hear the thinking behind it.