Playwright-test – cross-browser end-to-end test suite with Playwright(github.com)
github.com
Playwright-test – cross-browser end-to-end test suite with Playwright
https://github.com/microsoft/playwright-test
27 コメント
Playwright is a breath of fresh air next to selenium. And I maintain the perl selenium client and have written thousands of selenium tests!
So much so that I wrote what may? be the first third-party client for it: https://metacpan.org/pod/Playwright
Here's my writeup on why I like playwright versus selenium: https://troglodyne.net/posts/1617057517
So much so that I wrote what may? be the first third-party client for it: https://metacpan.org/pod/Playwright
Here's my writeup on why I like playwright versus selenium: https://troglodyne.net/posts/1617057517
That's a really good explanation. It's funny that they don't mention or allude to any of this in their page on why playwright: https://playwright.dev/docs/why-playwright/
That doesn't really surprise me to be honest.
Most of this is invisible to end-users of selenium, as it's just a hammer they pick up; the struggles of the maintainers is not (nor should it be) something they have to worry about.
Nevertheless, they probably could get some hay mentioning that their API implements a significant amount more functionality versus every other cross-browser testing framework.
That said, they really don't have to, the work really stands by itself.
Most of this is invisible to end-users of selenium, as it's just a hammer they pick up; the struggles of the maintainers is not (nor should it be) something they have to worry about.
Nevertheless, they probably could get some hay mentioning that their API implements a significant amount more functionality versus every other cross-browser testing framework.
That said, they really don't have to, the work really stands by itself.
It definitely manifests in ways I can see. I struggled for years as an end user of selenium with backwards compatibility issues, bugs and weird browser quirks.
It's pretty apparent that it requires an awful lot of maintenance to keep up with the browsers, so if this really does reduce the workload on them then that ought be noticeable on my end with fewer bugs, quirks and backwards compatibility issues. This is more exciting to me than all of the other features (I'm a bit dubious of the ability to detect if a page has really 'loaded', for instance).
It's pretty apparent that it requires an awful lot of maintenance to keep up with the browsers, so if this really does reduce the workload on them then that ought be noticeable on my end with fewer bugs, quirks and backwards compatibility issues. This is more exciting to me than all of the other features (I'm a bit dubious of the ability to detect if a page has really 'loaded', for instance).
In my experience, playwright is a lot, lot better on this than selenium.
You can even choose different events to wait for!
That said, there's no accounting for developers who think FOUCs are normal, etc and generally make your life as a tester and end user difficult.
You can even choose different events to wait for!
That said, there's no accounting for developers who think FOUCs are normal, etc and generally make your life as a tester and end user difficult.
That is an excellent write-up, and assuages the main concern I was still having with Playwright (Playwright itself addressing the main concern I had with Puppeteer, which was its focus on a single browser). Thanks for sharing!
Oh yes! Really excited to see this. I am using ms playwright for e2e tests for https://sqwok.im and have been very pleased with it. I've evangelized it whenever webdriver/selenium comes up in conversation as I think it's a huge improvement - clean api, multiple browser support, just "works".
The one thing that was missing was a purpose-made test runner. I'm using mocha currently, and while it works fine, there isn't a built-in way to e.g. run the test against multiple browsers w/o ugly for loops/before statements (that I'm aware of). It looks like this defaults to running against all browsers so you don't even have to think about it. The screenshot assertions also look nice!
Very cool! Excited to try this out.
The one thing that was missing was a purpose-made test runner. I'm using mocha currently, and while it works fine, there isn't a built-in way to e.g. run the test against multiple browsers w/o ugly for loops/before statements (that I'm aware of). It looks like this defaults to running against all browsers so you don't even have to think about it. The screenshot assertions also look nice!
Very cool! Excited to try this out.
Really interested as to why its using Jest-like assertions rather than just Jest itself?
It is possible, for instance, to extend the runner with an extra set of matcher that are out there & available to Jest?
It is possible, for instance, to extend the runner with an extra set of matcher that are out there & available to Jest?
This is built on top of a very interesting project from Microsoft called Folio[0] that I’ve used and while still very beta is shaping up to solve all of the issues I’ve had with jest while keeping most of the things I like about it.
[0]: https://github.com/microsoft/folio
[0]: https://github.com/microsoft/folio
Can anybody tell me about playwright vs puppeteer? The API looks very similar. At first glance it seems to be written by some of the same people. The major difference appears to be supporting different engines.
It looks like puppeteer may now support FF, but not WebKit/Safari.
It just seems like there is probably a story there.
It looks like puppeteer may now support FF, but not WebKit/Safari.
It just seems like there is probably a story there.
supposedly some of the key contributors are the same people who also built puppeteer and the objective seems to be taking it a step further to support ALL rendering engines [0]
>We are the same team that originally built Puppeteer at Google but has since then moved on. Puppeteer proved that there is a lot of interest in the new generation of ever-green, capable, and reliable automation drivers. With Playwright, we'd like to take it one step further and offer the same functionality for all the popular rendering engines. We'd like to see Playwright vendor-neutral and shared governed.
[0] https://github.com/microsoft/playwright/pull/711/files
>We are the same team that originally built Puppeteer at Google but has since then moved on. Puppeteer proved that there is a lot of interest in the new generation of ever-green, capable, and reliable automation drivers. With Playwright, we'd like to take it one step further and offer the same functionality for all the popular rendering engines. We'd like to see Playwright vendor-neutral and shared governed.
[0] https://github.com/microsoft/playwright/pull/711/files
We are using Cypress at my workplace and we're quite happy with it. It also has endpoint mocking, mobile emulation etc.
Out of curiosity, does anyone know of any advantages of Playwright when compared to Cypress?
Out of curiosity, does anyone know of any advantages of Playwright when compared to Cypress?
Cypress appears to have more features dedicated specifically to making testing easier, such as a user interface and various debugging additions and integrations into various other tools.
Playwright is just an API for controlling the browser, and appears to be far more powerful in that regard.
Compare the api documentation, and it's not even close: https://docs.cypress.io/api/table-of-contents
https://playwright.dev/docs/api/class-playwright
Playwright is just an API for controlling the browser, and appears to be far more powerful in that regard.
Compare the api documentation, and it's not even close: https://docs.cypress.io/api/table-of-contents
https://playwright.dev/docs/api/class-playwright
It looks like Cypress added Firefox & Edge support last year but initially it was just Chrome.
Playwright also has a python version (https://github.com/microsoft/playwright-python)
And I just discovered that they now have a real nifty debugger you can use to inspect/step-through tests as they run (https://playwright.dev/docs/next/debug/#playwright-inspector)
Playwright also has a python version (https://github.com/microsoft/playwright-python)
And I just discovered that they now have a real nifty debugger you can use to inspect/step-through tests as they run (https://playwright.dev/docs/next/debug/#playwright-inspector)
They also have a code generator that can record your actions and turn them into scripts
If cypress works for you that’s great, playwright doesn’t have all of the same tools but it does excel at cross browser testing. It runs safari, Firefox, and chrome.
We’re working on plugging in playwright into a cloud service for visual testing @superadmin.so, running multiple browsers in Linux can be pretty hairy to setup.
We’re working on plugging in playwright into a cloud service for visual testing @superadmin.so, running multiple browsers in Linux can be pretty hairy to setup.
Been using it at the Fortune 500 and some other projects I work on and folio fixtures (the test runner under playwright-test) is really nice can pass POM, db connection, JWT token getter directly into your test as test function parameters. Test look like jest. Just wish Webstorm/pycharm would get built in integration
The project I work on switched from Puppeteer to Playwright in order to increase our browser coverage for visual output tests about a year ago and we've been very happy with it.
For my last internship, I had to build an e2e testing suit. After studing the various options already on the market, I ended up choosing Playwright and I didn't regret it.
How does puppeteer compare with Playwright?
Puppeteer does a few more things, but only works for chrome.
Both of them are essentially wrapping devtools protocols. AFAIK, much of the playwright approach was guided by trying to Hew as closely to the puppeteer approach, but cross-platform. Both the APIs are very similar.
Both of them are essentially wrapping devtools protocols. AFAIK, much of the playwright approach was guided by trying to Hew as closely to the puppeteer approach, but cross-platform. Both the APIs are very similar.
Does playwright work out of the box in CI systems (github actions) or we have to explicitly install the browser binaries? I am planning to use playwright-java (https://playwright.dev/java/docs/intro)
Playwright will install the browsers seamlessly, also you can opt into using the browsers that are already installed on CI. See https://playwright.dev/docs/ci and https://playwright.dev/docs/browsers for more details.
It's Puppeteer but not only for Chrome.
Helium is a much better, faster alternative. It offers fallback to Selenium WebDriver.
https://github.com/mherrmann/selenium-python-helium
https://github.com/mherrmann/selenium-python-helium
[deleted]
Playwright feels much more like you’re simply driving a browser because you are — it gets out of your way like any good tool should, so you can debug your tests instead of your browser automation toolkit. The trade-off of Playwright is that meant, at least early on, that it wasn’t “batteries included” and the ecosystem around it is only just now starting to mature. This is a great time to start using Playwright IMO.
One gripe with Playwright is that you lose the ability to easily deploy your tests to services like Browserstack where you can do true multi-device testing. For that you need to use Selenium, or (recently?) Cypress. Because of the nature of Playwright only targeting specific browser engines, it seems unlikely that Browserstack would ever fully support it.
But there is probably a place for both, with Playwright closer to the bottom of the pyramid and Selenium / Browserstack toward the top for only the most critical e2e acceptance tests. You could also write your tests in such a way that they could mostly run on Selenium with just a few changes to how you orchestrate them, although then you might end up chasing the “lowest common denominator” of what’s available in either paradigm.
As an aside, I’d love to hear the story of how the Puppeteer team left Google for Microsoft while taking their toys with them. I wonder if there is some drama there? :)
[0] https://docs.cypress.io/guides/references/trade-offs#Permane...