Its happened… we got a teenage dev out of college who wants to replace my beautiful Robot framework web integration thats part of our CI process with Playwright, and demo it front of management (its the I’m new here look at what I’ve been using scenario)
I’m not familiar with Playwright but at a glance and open minded as I can, I can’t see much in the context of the way we use web automation, that it can do any better? Can someone give me some ammunition to smite this upstart
(We use Microsoft platforms and languages so I guess the problem is RF/Python is of the beaten track a bit with Playwright being owned by Microsoft now…)
Robot Framework Browser combines the strengths of both Robot Framework and Playwright. It’s a win-win, really.
When going with Robot Framework Browser (and thus Robot Framework), you enable all kinds of automation just in case you need it. With plain Playwright, you limit yourself to web automation. If your projects grow outside web applications, choosing Robot Framework will allow you to automate those parts, too.
Add rcc, and you also solve the “how do I set up an environment easily and in a way that works everywhere” question. Install rcc (or use VS Code with Robocorp Code extension), create your project, select the Playwright template, and that’s it.
Playwright isn’t a direct alternative to Robot Framework. It’s a browser automation library, and an alternative to Selenium. Both require a test runner, which is what Robot does (though the Node.js bindings for Playwright seem to include a simple test runner). Robot has libraries for both: Browser library is built on Playwright, and SeleniumLibrary is built on Selenium. If your colleague’s point is that the Playwright API is better than the Selenium API (arguably very true) then that isn’t an argument against using Robot, that’s an argument for migrating to Browser library.
Whatever your reasoning was for choosing to write tests in Robot Framework over Python+Selenium+pytest (for example) would likely be the same when considering Python+Playwright+pytest or Node.js+Playwright. It might be worthwhile to ask whether that reasoning still stands up in hindsight.
So I installed the RF browser and ran some demo scripts in Ride but should I be disappointed that the Keywords aren’t the same as Selenium and I’ve got to rewrite all the tests as they are JS style syntax just to achieve the same result and omit having to use a few managed sleeps here and there?
Playwright comes with builtin binaries for all browsers, no additional drivers needed which is great but presumably we have to keep the packages updated as the browser version updates over time vs. just having to update a single driver.exe file (and its not often one needs to update the Selenium lib) if I have understood correctly this could be an issue to maintain in certain environments.
I do like Playwright if I’m sounding a bit biased to RF
The Selenium eco-system has been around the longest but it has it’s weaknesses (stability, wait handling). PlayWright is the successor of Puppeteer and it has gained much traction the past few years. It handles waiting much better than Selenium, it subvendors the browser engines (so no breaking pipelines with Selenium / webdrivers / browser updates at random intervals) and handles things like iframes and shadow DOM. Also it’s much faster than Selenium in many common test scenario’s.
Now Robot Framework or not isn’t / shouldn’t be the question here, since there’s RF libraries building on Selenium and PlayWright.
What you should be looking at / discussing is whether the current solution has issues that will be (easier) solved with a PlayWright based solution or not. Would migrating to PlayWright make future development of the tests more stable, faster, more reliable or not? Is there a business case for a migration or not?
I’m going to sound like sour grapes here but after playing around with Playwright I can’t see that in my scenario it would provide any benefit. I appreciate it maybe a little faster but I don’t buy this “Sleep & Wait handling” thing being as big an issue as people are making out, I just think people have written poor tests and not managed how the waits are used and interestingly enough lots of the YouTube demos of Playwright are having to add in managed Waits anyway so it seems you can’t do away with them altogether. The browser driver updates are a real pain thought.
Does anyone know if there are plans for Selenium to be updated in such a way as not to rely on browser drivers?
Well, your target application may not be comparable to other applications where people are seeing the benefits of the waiting handling that Playwright provides. From first-hand experience I can say that the difference in amount of code and the reliability of that code can be quite large. In Slack, Browser users are reporting up to 50% reduction of test execution times after migration of SeleniumLibrary to Browser.
But those results cannot be compared with yours since the target application isn’t the same. That’s also why your assumption that people getting the benefits from Playwright didn’t have proper tests / wait strategies may very well be incorrect in many situations.
Relying on browser drivers is a key element of the Selenium architecture, so I doubt anything will change in that area anytime soon.
I have not use Playwright, but if the Browser is build into the framework. Then it’s not good for me. Management sometime asked to run tests against older versions of Chrome, FF, or Edge. Second, RF supports RestAPI, iOS, Android, and Windows platform. Playwright lacks in all those. It might be a good candidate or POC for now, but might not standup in the future of extension in tests. Lastly, if use RF with subscription of BrowserStack, (any browser and OS combo, iOS, Android) you will eliminate the driver.exe headache, but paid a monthly price for that.
I agree with the above points that there must be issues with the current solution that will be solved by Playwright, rather than to switch the environment just that because it is more fun and newer. If RF is already used with Selenium, then the migration is not that difficult although the keywords are a little bit different.
In my case, dealing with automating a Vaadin based web application, which is statefull and very dynamic, I was using Selenium and the reason to switch to Playwright Browser library was that I could not use Selenium with 0 speed (need to use Set Selenium Speed 2 - e.g. 2 seconds), otherwise I would get Stale Reference Exception or Invalid Element State Exception all the time. This means when I switched to Playwright Browser library, with no more Selenium speed lowering, which is a hidden sleep anyway, the execution speed went skyrocket.
And even if all major browsers are integrated with Playwright and it needs updating, still it is possible to use any locally installed browser, so no issue on this point. The other point is that for example Robocorp managed to automatically update the drivers with their "Open Available Browser’ keyword from RPA.Selenium library, so maybe it is worth looking there how they solved it and integrate this automation if it helps your project.
