Whatever your opinions on Selenium are, it was (and is) a good UI automation tool. With the advance of new tools though, there comes a time when you need to look at what else is out there, and is the cost to change worth it. Which is how my team started a journey to migrate our Selenium UI tests to Playwright instead. If Selenium was good, Playwright is better.
Why Playwright? and not Cypress / Webdriver.IO / Robot / TestCafe?
This was a really simple decision for us. We had previously investigated alternatives to Selenium when deciding which modern test framework to use for testing our new front end experiences. They are being built as micro front ends, rather than existing as part of our central code monolith. At that time we had whittled the options down to Playwright or Cypress. After undertaking a proof of concept for both, Playwright won out. Primarily because it was faster.
When it came to deciding which framework we should look at for replacing Selenium, it didn’t make sense to consider options other than Playwright. We started off with a proof of concept again. This time our aim was to prove that Playwright would solve the problems we face with Selenium. So we started with a handful of tests that had proven extremely difficult to create reliably in Selenium. The result? The tests are reliable and massively faster. 264% faster! A test that took 106 seconds in Selenium, and was flaky, took just 30.6 seconds in Playwright, and is reliable!
Differences between Selenium and Playwright
Selenium uses a webdriver (a standalone piece of code between your tests and the browser) in order to control the browser. It works by translating test cases into JSON and sending them to the browser. The browser then execute the commands and send an HTTP response back.
Playwright uses a websocket connection to the browsers to control it directly without any middle layer. The connection remains open for the duration of the test and all instructions are sent via that one connection. This is part of why Playwright is faster than other test tools.
Selenium runs against the end user browser product, such as Chrome, Edge, Safari etc.
Playwright runs against browser engines, such as Chromium, Webkit etc.
Both frameworks support a massive range of languages, in our case though we would be moving from Selenium written in C# to Playwright written in TypeScript
Was changing languages a big overhead?
Yes and No. For some of our engineers, that have little experience with TypeScript and Node in general, the bar to entry is higher. For others, it was a a welcome change because they were already familiar with it from working with our micro front ends. Given that the majority of engineers working with the framework would be Quality Engineers or Front End Software Engineers, we felt that this was an acceptable situation.
We’ve also been sure to use good software design patterns when creating our Playwright framework. This makes the bar to entry much lower for those less familiar with working in Node / TypeScript. You can read more about our approach to designing the framework on the Zoopla blog in a post entitled Make Engineers Love Playwright With These Software Design Patterns.
How long did it take to migrate to Playwright?
The project is ongoing. Now we have proven that it is worth the effort, we are taking it one test at a time. We are focussing on those that have proven to be flaky in Selenium, and those that take longest to run. It is also being worked on as a side project, outside of the Quality Engineers day to day work. Having said all of that, progress is good and we expect it to take just a few months.
As part of the journey, once a test is migrated to Playwright we are disabling, but not removing it, from Selenium. This reduces the runtime for the Selenium tests but gives us an easy route to switch a test back if we run into issues with the new implementation. On that note, we are only human, and we make mistakes sometimes.
I was a sceptic. When my team presented the idea to me that we should migrate the Selenium tests to Playwright, I expected it to be a world of pain. I had played around with Playwright, you may have seen my post about Building Better Front Ends with Monkey Testing and Gremlins.js, but I wasn’t convinced it could solve the issues we’d experienced. We had invested so much time into making the Selenium tests work as well as they did. Did we really want to go through that again with a new framework?
I’m not one to close down an idea like this though. I helped the team to scope what questions they needed to answer from a proof of concept and ensured they had some time to investigate properly. I am happy to say that they proved me wrong.
Playwright is faster, more flexible and more powerful. It makes writing high quality, valuable, and reliable tests much simpler. Now I look forward to the day I get to delete the Selenium framework. Not because it was bad, but because Playwright is better!
Subscribe to The Quality Duck
Did you know you can now subscribe to The Quality Duck? Never miss a post but getting them delivered direct to your mailbox whenever I create a new post. Don’t worry, you won’t get flooded with emails, I post at most once a week.