Playwright is a browser automation tool similar to Selenium (WebDriver). These tools can be used as such to implement end-to-end tests that simulate actual user actions through the browser. Often, those are used through higher-level testing libraries such as Vaadin TestBench (built on top of Selenium) or Robot Framework.
Playwright has recently increased its popularity and has some notable advocates. Even though there aren't as many handy extensions available for Playwright as there are for Selenium (through Vaadin TestBench), it is a proven option to test Vaadin applications as well. There is also an article in the Vaadin Docs to get started with Playwright and Vaadin.
Screenshot: A snippet of a diff presenting differences between a page object helper written using Vaadin TestBench (red) vs. Playwright (green). Principles are exactly the same. The usage of Playwright resembles testing with plain Selenium without the typed higher-level selectors and component wrappers provided by TestBench.
Why Playwright over Selenium?
In the past, when Selenium was the de-facto solution, I avoided writing automated end-to-end tests for my add-ons due to their maintenance cost. Selenium commands actual browser binaries, and these tend to change frequently. Especially with my community add-ons, where I don’t have the luxury of using our well-maintained internal Selenium Grid (containing a number of virtual machines awaiting instructions from Selenium scripts), keeping the WebDriver versions in my projects in sync with the browser binaries on my workstation has been a constant issue.
In Playwright, the default behavior is for Playwright itself to maintain the browser binaries. It downloads custom browser binaries known to work together with the version of Playwright in use. This approach saves a lot of time and frustration, particularly in small to medium-sized projects. When you return to a project after a year, everything just works.
Another advantage for Playwright is its more intuitive API with shadow DOM. With a few exceptions, “locators” work in the shadow root by default. This playing field, however, has become more level now with Selenium 4 and its WebElement.getShadowRoot()method. Nonetheless, referring to some internal parts of Vaadin components may still be less of a hassle with Playwright than with pure Selenium, for example.
The best solution for add-ons?
Today, if I were to choose between OSS tools Selenium and Playwright, I’d opt for Playwright for its stability. Vaadin TestBench, with its extensive selection of helpers for all Vaadin components, is an obvious choice for apps with a large set of end-to-end tests.
However, when developing add-ons, my preference leans towards Playwright despite having a TestBench license. When testing an add-on, interactions mainly involve the add-on component itself, which is more convenient and stable with Playwright. Additionally, as Vaadin add-ons tend to be Apache 2 licensed OSS projects, it’s preferable for potential contributors not to require a license in case they want to draft a pull request.
Recently, I packaged a couple of helpers for this purpose into a new library called Mopo. With Mopo and Playwright’s Java APIs, you can, for example, build a smoke test with just a few lines of code that opens each test view in your add-on project and verifies they open properly without JS exceptions.
@Test
public void smokeTest() {
mopo.getViewsReportedByDevMode(browser, rootUrl).forEach(viewName -> {
String url = rootUrl + viewName;
page.navigate(url);
mopo.assertNoJsErrors();
System.out.println("Checked %s and it contained no JS errors.".formatted(viewName));
});
}
A code example that uses Mopo, Playwright & Vaadin in development mode and verifies that add-on test views open up properly and rendering causes no JS errors.
The Mopo library also contains some other higher-level helper classes to command Grid, ComboBox, and DatePicker, which can also be handy in generic Playwright and Vaadin usage.
To learn more about how to get started with Vaadin and Playwright, check out our documentation.