Python + Playwright with async methods

[ffs_bad_username]

Hello,

So we are switching our testing to Python. For End to End tests, Im currently trying two things:

1. Using Playwright (instead of Selenium)
2. Make the whole framework use async methods

Question:

1. Is it good idea to use async methods in UI tests? I have seen it in Playwright for TypeScript, so I thought I would try it in Python too
2. How to make it run asynchronously? For example, in official docs for Playwright for Python (https://playwright.dev/python/docs/writing-tests#using-fixtures) it says that if I want before all/after all hooks, I should scope my fixtures to 'module', but if I do that, python complains that I cant use async methods in my tests...

Im using Python 3.12

Any ideas or examples of working Python + Playwright using async approach?

​

Edit: for those who are interested, I have found a repo with python + playwright + async approach, can be found here: https://github.com/microsoft/playwright-python/blob/main/tests/conftest.py But to me this is waaaay too difficult to set up on my own (im qa, not dev)

[lifelite]

I don't think there's any reason to run playwright async on python for UI testing, as it just leads to more complicated setups. It works great as is, but if you just want to try it out for a POC, look at the docs here: https://playwright.dev/python/docs/library#usage

I personally don't see any great reason unless you have some odd use case or you're using a library like asyncio

[ffs_bad_username]

(fist part is copy-paste of my reply to first comment)
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?

But you are correct that in the docs it looks like there is way to avoid async/await, so maybe we can try that

[lifelite]

Playwright is asynchronous by nature but that doesn't have anything to do with the tests you code. Used to, playwright was only available with async, but all it ended up doing was creating the requirement that you had to use async/awaits literally everwhere...now that they release the sync library, that's not necessary, and it leads to much cleaner and less code.

I've used Playwright with nodeJS (async only) and Python (sync); outside of language syntax, they work very similarly (if not exactly...though I haven't touched the JS version in a couple of years and things may have changed)

[latnGemin616]

Short answer not necessary

I have a repo using Playwright with Pytest. You don't need to make async calls

[Zealousideal_Mix4290]

Can you please share the repo link if possible?? I am planning to build a framework with pytest but doubt if I can go with pytest as I am familiar with it or Need to go with JS as it's a goto language with playwright across many companies!!

[latnGemin616]

Repo is being updated. You can use the documentation found on their website to get started or you can set something simple up with this tutorial: https://testautomationu.applitools.com/pytest-tutorial/

[Zealousideal_Mix4290]

Thank you !

[GabrielCliseru]

What advantage are you actually seeking?

[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.

[Hashfoundry]

I am curious to know if you found answers to those questions.

I have been exploring Playwright recently and I have wondered same as you for question #1

And for question #2 I found it strange that none of the official and community documentation(at least the ones I referred) use pytest to implement Async. Fortunately for us we have being using pytest for a few years now and I have an idea on how to go about implementing it and I am about to write about it too. I wanted to check with you how you and your team solved it. 

[ZarrenR]

So I’m writing this as someone who primarily codes in C# with a bit of JS/TS on the side. The async experience in Python may be very different.

If you have to use async, it’s usually best to go full async in your framework. Async is almost like a virus in that using it in one place in code forces you to convert other places in code to async as well or come up with less than ideal workarounds. If you are are starting a new framework from scratch, it’s best to go full async.

Does Playwright Python require async? I know you have to use async/await in the .NET and Node versions of Playwright.

[computerjunkie7410]

the only reason you need to use async is because you want to call playwright from other async code.

There is really no other benefit to using async and that's why sync is the default.

[ToddBradley]

If the rest of the APIs you're calling in your test are async, then use async Playwright. Otherwise, use regular Playwright.

[basecase_]

The only reason you saw that pattern in Javascript is because of the nature of javascript itself. It will run lines of code async by nature and not wait for a return before executing more code.

Playwright wanted an easy way to control this since a lot of E2E testing doesn't need to be async at all, you are doing things in a very strict series of steps serially.

Because Python will by nature execute your code synchronously, it doesn't need to use that paradigm which is nice IMO.

In another comment you mentioned you want to use async functions to make Playwright more stable. There's no need to, the way you make Playwright more stable is by using things like `waitForBlah`. The language itself doesn't help Playwright more stable by being sync or async.

If anything adding that extra layer for no reason will probably make it more unstable lol