Correcting Wrong ‘Playwright’s Advantage over Selenium” Part 2: “Playwright has Parallel Execution Support”

An automation framework should NOT concern parallel execution, which falls under a Continuous Testing server’s responsibilities.

The first article of this series was immediately awarded “Boost” status by Medium creators. I will continue to correct the second wrong claim, “parallel execution support”, in this YouTube video, “Playwright vs Selenium: What Advantages Make Playwright the Winner in Automation Testing Battle 🏆”. Again, like all his other claims, this presenter is wrong, this article explains.

This article series:

• “Playwright is Modern and Faster than Selenium” 😒
• “Playwright has Parallel Execution Support” 👎🏽
• “Playwright has Native Auto-Waiting Mechanism” 👎🏽
• “Playwright has a native test runner” 👎🏽
• “Playwright has native HTML Reporters” 👎🏽
• “Playwright Features Can be Configured in one Configuration” 👎🏽
• “Playwright supports a range of Testing Types, e.g. API Testing, Component Testing, …” 👎🏽
• “Playwright UI Mode, CodeGen, Debugging support.” 👎🏽
• “Playwright ARIA locator support” 👎🏽
• “Playwright has frequent releases” 👎🏽
• Wrap Up

Table of Contents:
· Claim 2, “Playwright has Parallel Execution Support”. (It's better without it)
· Parallel Execution Support is a Continuous Testing Feature and shall not be in the automation framework.
· Parallel Execution in Playwright in a perfect world.
· The Problems with Playwright Parallel Execution
· Parallel Execution in the real world

Claim 2, “Playwright has Parallel Execution Support”. (It's better without it)

Playwright fans might think, “Zhimin, your first article may be valid, but surely, you can’t argue with this, as Selenium WebDriver…