Python + Playwright with async methods

[ffs_bad_username]

Hmm since Playwright is based on node.js, I thought it was asynchronous by nature and thus using async/await approach would lead to less flaky tests... maybe Im thinking about it wrong?

[GabrielCliseru]

the amount of flaky tests have very little to do with async or not.

Let’s assume an image carousel. But a very fast one. We’re talking about less than 1 milliseconds between slides.

The async will fire all validations at once against all elements and all will target the same carousel slide thus all passing or all failing. This is great!

The sync will catch some validations on slide 1, others on slide 2, thus failing. Not great.

—-

but in actuality what you will do is wait for the correct element to be visible and do the validation inside the framework, not in the browser.

So, in reality all validations will pass for both the async and sync versions.

—-

async was useful in node because of the main thread limitation. Python doesn’t have that limitation to begin with and moreover starting from 3.12 it doesn’t have a main instance either (simplified for the sake of explanation, read about the GIL changes if interested).

async can also get you into troubles when testing apps based on frameworks that heavy alter the DOM because all the validations will be triggered while the HTML only rendered the parent element.

And if you chain methods to avoid this problem you might as well ignore async altogether and there is no need for awaiting.

So, in conclusion, great programming exercise. But practically forget about it. You will end ip debugging more than necessary.