DEV Community

Cover image for How to Reproduce CI Failures Locally in Playwright
6

How to Reproduce CI Failures Locally in Playwright

Have you ever run a Playwright test locally, watched it pass with flying colors, and then pushed your code—only for it to fail on CI? Debugging these inconsistencies can be tricky, but there’s a simple trick that can help you figure out what’s going wrong.

The Key to Diagnosing Flaky Tests

When a test passes consistently on your local machine but fails on CI, the issue is often related to timing, race conditions, or resource constraints. To expose these hidden problems, you can use Playwright’s --repeat-each flag.

Step 1: Run Your Test Multiple Times

Use the following command to run your test 100 times:

npx playwright test file-with-failing-test.spec.ts:20 --repeat-each=100
Enter fullscreen mode Exit fullscreen mode

This will execute the test repeatedly in multiple workers, increasing the chances of catching intermittent failures. If there’s a race condition or an unstable dependency, it’s more likely to show up during repeated runs.

Step 2: Stress Test with More Workers

Sometimes, running the test repeatedly isn’t enough, especially if the failure is triggered by CPU or memory constraints on CI. In this case, you can stress your system by maximizing the number of workers:

npx playwright test --repeat-each=100 --workers=10
Enter fullscreen mode Exit fullscreen mode

If your local machine has 10 CPU cores, Playwright will utilize them to simulate the load your test might face in a CI environment. This can help uncover concurrency issues and race conditions that may not appear in single-run scenarios.

Step 3: Stop on First Failure

Running a test 100 times can take a while, but you don’t have to wait for all runs to complete. Use the -x flag to stop execution as soon as a failure occurs:

npx playwright test --repeat-each=100 -x
Enter fullscreen mode Exit fullscreen mode

This will save you time by immediately identifying when a test starts failing under stress.

Final Check: Ensure Stability Before Pushing

Once you’ve identified and fixed the root cause of the flaky test, rerun the test with --repeat-each=100 to confirm stability. If all 100 tests pass, you can push your changes with confidence, knowing it’s far less likely to fail on CI.

Conclusion

Debugging flaky Playwright tests on CI doesn’t have to be a guessing game. By leveraging --repeat-each, --workers, and -x, you can reliably reproduce failures locally and fix them before they cause problems in your pipeline.

If you found this guide helpful, be sure to share it with your team and check out more Playwright testing tips. 🚀 Happy testing!

🔹 Want to see this in action? Check out our latest video:

Useful links

AWS Security LIVE! Stream

Stream AWS Security LIVE!

The best security feels invisible. Learn how solutions from AWS and AWS Partners make it a reality on Security LIVE!

Learn More

Top comments (0)

ACI image

ACI.dev: Best Open-Source Composio Alternative (AI Agent Tooling)

100% open-source tool-use platform (backend, dev portal, integration library, SDK/MCP) that connects your AI agents to 600+ tools with multi-tenant auth, granular permissions, and access through direct function calling or a unified MCP server.

Star our GitHub!

👋 Kindness is contagious

Dive into this insightful write-up, celebrated within the collaborative DEV Community. Developers at any stage are invited to contribute and elevate our shared skills.

A simple "thank you" can boost someone’s spirits—leave your kudos in the comments!

On DEV, exchanging ideas fuels progress and deepens our connections. If this post helped you, a brief note of thanks goes a long way.

Okay