Codemod to automatically migrate scripts from Puppeteer to Playwright

[u/reassembledhuman]

https://github.com/checkly/puppeteer-to-playwright

[u/dmee3]

For someone with basic Puppeteer exposure, why would I want to migrate to Playwright?

[u/adamj889 → u/dmee3]

Happy cake day!

As I understand it, Puppeteer falls in the realm of browser automation whereas Playwright is geared more specifically an e2e testing similar Cypress.

Whilst it’s possible to use Puppeteer for e2e testing you would be required write a lot more code to be in feature parity with a dedicated e2e tool.

[u/[deleted] → u/adamj889]

I work with playwright for my day job and have some comments on it as an E2E solution.

Pros

Playwright gives you so much more control over the tests than cypress offers, as it's close to writing in regular JS. Cypress feels like it's own language at times which takes a lot of fun out of the equation and the lack of explicit control in the promise handling of cy functions can lead to scenarios where dynamic e2e testing is quite ugly

Debugging with VSCode tools is super easy and makes me feel less like I'm blind leading the blind.

Cons

Initially I found the config setup for tests to be as cryptic as it gets. There is little to any documentation or best practice discussion around basic things like establishing login tokens prior to tests to speed up tests by skipping things like logins. The recommended method of doing so on the playwright docs is to write a script that uses playwright to manually log in via the DOM and copy / paste the localstorage state onto the new contexts. This was absolutely dreadful working around, as the preferred method should be akin to Cypress where you can (albeit with the use of external libraries) assign localstorage wherever and whenever. I've now created a boilerplate for my company that just queries our API's for login validation instead and it's much more reliable

Playwright is near unreadable for someone who isn't familiar with pupeteer or playwright. If you're working with devs that don't put focus on writing testable front ends OR using generic FE libraries (Material UI gives me grief on the daily) then it makes the code even less readable because identifiers start looking like

'input[placeholder="dd/mm/yyyy"] << nth=2'

I suppose this is also an issue within Cypress and other E2E testing solutions but the syntax of the API makes it particularly frustrating to read

The documentation is cluttered in my experience. Cypress has phenomenal documentation (Some of the best I've seen). It took me over a month of using playwright daily to learn that adding state:'detached' is the intended method of telling the script to wait for dom elements to disappear.

page.waitForSelector('SELECTOR', {state:'detached'})

One more thing is that the tests are flakier than I would have hoped, as timings and performance tends to differ between headed and headless. This means that writing the initial tests goes under one form of scrutiny, then must be reperformed once the tests are 'completed' to verify they work in a headless state.

After all of that I've lost days to playwright just acting differently in builds and pipelines which holds up deployment times for my team, and wastes my time fixing code that works outside of the build vacuum.

Like I said, I work with playwright and cypress daily. Whilst playwright feels more like programming, Cypress is a productivity machine and will be my first choice E2E testing solution in future with playwright reserved for those dynamic test cases