Does it have a mode where it can drive a real browser? Most real-world UI test matrixes for web apps want the tests run on their real targets for any final acceptance. "Fake" headless browsers tend to be more useful for first-tier CI and just keeping tests warm.
If it can only drive its internal browser engine, that'd possibly be a big argument against it for any test strategy I was architecting. I'd want the tests to be portable and usable cross-browser for acceptance--particularly UI-driven E2E tests, since that's really the only time they are critical.
Playwright does use "real" web browsers (Chromium, Firefox, WebKit). It just supports specific versions, as otherwise it would be difficult to maintain. It runs them in headless mode, which most browsers support, and should behave exactly as a headed version would. You can start a test in headed mode if you want to see the browser window.
The era of custom headless browsers like PhantomJS, or Selenium/WebDriver for that matter, is dead, IMO. The Chrome DevTools Protocol is the modern standard API to interact with a browser programmatically.
Oh, OK! I misunderstood the comment entirely then. Thanks for correcting me there, especially since I was apparently too lazy to look for myself.
This does sound more promising then, if they've found new ways to add maintainability or QoL aspects to record/replay. As I said elsewhere, I think r/r gets a bad rap, and those sorts of improvements would increase the number of situations where it makes sense (at least for testing in incubation).
I think the mistake was in the comment you replied to, that suggested Playwright used custom browser builds.
I do recommend giving it a try. The web browser automation landscape is much more reliable these days for writing E2E tests than back when Selenium was state of the art.
Yep, it’s just a matter of setting headless=false and it can launch a normal firefox/safari/chromium exe. You can even have it attach to an existing instance of your personal browser (via the debugging protocol).
If it can only drive its internal browser engine, that'd possibly be a big argument against it for any test strategy I was architecting. I'd want the tests to be portable and usable cross-browser for acceptance--particularly UI-driven E2E tests, since that's really the only time they are critical.