How Painful IS It To Move From SeleniumLibrary To Browser Library?
03-02, 15:30–16:00 (UTC), Gather Town

As Playwright battles for the hearts and minds of Selenium die-hards, we made the decision to see what Playwright could do. Follow along as we make the switch from a Selenium Library-based set of tests to Browser Library. Some aspects were seamless while others have proven to be far less so. And finally, what DID we get? Stop by and find out!

"Selenium Library has long been the go-to tool for automating web testing in Robot Framework. With the growth of Playwright as a competing tool, Browser Library, a Robot Framework library built on Playwright, has emerged as an alternative. Browser Library has been heralded as the faster-better-cheaper alternative and we wanted to see if that was true AND how hard it would be to get those benefits.

What we found is that Browser Library isn't a drop-in replacement. I will go over both the simple and the complex aspects of this conversion.

We worked with the limitation of keeping our tests functioning with Selenium while being able to simply use a command line parameter to select the Browser Library.

We did have the benefit of an extensive set of abstraction layers that reduced the direct usage of Selenium Library calls at the test and high-level keyword levels.

- Browser Library supports a subset of the Selenium locator/selector strategies (and fortunately, we used few to none of the non-supported implementations in our original Selenium, hence this was “easy”)
- Interacting with Iframes in Selenium is significantly different than Browser Library but making that work in Browser Library, simply required adding the iframe selector to the front of the locator.
- For every Selenium Library keyword, we found very straightforward Browser Library equivalents.

- To support both libraries, direct calls to either library needs to be hidden in an abstraction layer utilized by the tests proper.
- Iframe interactions seem to be more stable out-of-the-box with Selenium Library.
- Existing use of other libraries that depend on Selenium will require our own implementations or convincing those teams to also support Playwright.
- We had extended some Selenium keywords which was implemented in Python. Browser Library extensions requires a working knowledge of NodeJS.

What did we find?
- SPEED! Over a small set of 60 smoke tests, we have seen a reduction of nearly 50% of our execution time with Browser Library.
- The current activity on the Browser Library seems to be more robust than the Selenium Library and the Slack channel support has been excellent.
- Iframe error reporting in Browser Library is decidedly lacking."

Codebase for RoboCon 2023 talk. Tests that can run in Browser Library or SeleniumLibrary.

See also: Codebase for RoboCon 2023 talk. Tests that can run in Browser Library or SeleniumLibrary. (293.0 KB)

Samuel Tillinghast is a software engineer from Buffalo, NY. He has a BS in Computer Science from Rochester Institute of Technology and has worked at Buffalo Computer Graphics in test automation since 2020. He is a big fan of indie music and will sing along to almost any song from the 80s. He looks forward to meeting people at RoboCon and learning and sharing with everyone else.