by Alex Chaves – Senior QA Advisor/Automation Engineer
In a previous blog entry we discussed some topics where Selenium and Playwright are different, here is the link if you would like to start the reading from there.
In this one we will discuss two main topics:
If you want to record a test in Selenium the easiest way to do it is through the Selenium IDE plugin, it will be installed in your browser, and then it will record every action that you made.
In the old times when Selenium started and even 5 years ago this feature was flaky, especially for the creation of locators, many of the code generated will involve xpaths, if you have been working for a while in automation you know that xpaths are a nightmare from the maintenance point of view.
In the latest version of the Selenium IDE, this has been improving, finding the elements using the “by” class which helps with maintenance and the hierarchy of recommended locators.
I guess that the biggest problem from this code generated is that it does not follow the page object pattern, which means that at the end you will probably just copy the lines of code that you are looking for to interact with the webpage and get rid of the remaining code generated.
For a simple test like go to google and search for “automation testing” and then validate a text from the search bar this is the code generated by Selenium IDE:
public void () {
driver.get(“https://www.google.com/”);
driver.manage().window().setSize(new Dimension(1456, 928));
driver.findElement(By.id(“APjFqb”)).sendKeys(“automation testing”);
driver.findElement(By.cssSelector(“#ERWdKc b”)).click();
{
List<WebElement> elements = driver.findElements(By.cssSelector(“.uEierd:nth-child(3) .v5yQqb”));
assert(elements.size() > 0);
}
assertThat(driver.findElement(By.id(“APjFqb”)).getText(), is(“automation testing tools”));
}
On the other hand, if you want to record steps using Playwright, after configure the environment you must execute this line (at least if you are working using Python):
playwright codegen mytestpage.com/practice
Run codegen and perform actions in the browser. Playwright will generate the code for the user interactions. Codegen will look at the rendered page and figure out the recommended locator, prioritizing role, text and test id locators. If the generator identifies multiple elements matching the locator, it will improve the locator to make it resilient and uniquely identify the target element, therefore eliminating and reducing test(s) failing and flaking due to locators. (Playwright, 2024)
When we execute the same test using Playwright codegen this is what we get:
page.goto(“https://www.google.com/?gws_rd=ssl”)
page.get_by_label(“Search”, exact=True).click()
page.get_by_label(“Search”, exact=True).fill(“automation testing”)
expect(page.locator(“#APjFqb”)).to_contain_text(“automation testing”)
page.get_by_role(“combobox”, name=”Search”).click()
expect(page.get_by_role(“combobox”, name=”Search”)).to_be_visible()
page.get_by_role(“combobox”, name=”Search”).click()
expect(page.get_by_label(“automation testing tools”).get_by_text(“automation testing tools”)).to_be_visible()
If we compare both codes you can notice that Playwright uses the label to locate elements in comparison to id’s or cssSelectors being used by Selenium IDE, the first benefit of this approach from Playwright is improving readability, the second one is that it is more unlikely to change the text than the dynamic id or name of the CSS class. And if the text changes anyway it was probably required to update the test even if it was not being used as a locator.
Another difference is that Playwright uses the .get_by_role method, where it describes exactly the kind of component that you are interacting with, this is really useful for maintenance when you come back to debug a test that is updated you know exactly which web element you are interacting in the test.
This comparison is straightforward while Selenium is primarily used for automating web browsers for testing purposes, it’s not typically the best tool for API testing. API testing involves testing the functionality and performance of the APIs directly, usually by sending requests to the API endpoints and analyzing the responses.
While Selenium can technically be used for API testing by interacting with the web interface of an API documentation tool like Swagger UI, it’s not the most efficient or appropriate tool for this purpose.
On the other hand, the feature of API testing for Playwright is out of the box, you can find more details here.
Comprehensive Testing: With a single tool, you can cover both the front-end functionality of your application (UI testing) and the back-end functionality provided by APIs.
Continuous integration improvement: Being able to combine both types of automation testing will improve the quality of the continuous integration validation for your builds.
End-to-End Testing: Combining functional testing and API testing capabilities enables you to perform end-to-end testing seamlessly. You can simulate user interactions through the UI while also validating the behavior of the underlying APIs, providing a more realistic testing scenario.
Efficiency: Using a single tool for both functional and API testing can streamline your testing process and make it more efficient. You don’t need to switch between multiple tools or maintain separate test suites for UI and API testing, saving time and effort.
Consistency: Having consistent testing practices across both UI and API testing helps maintain consistency in your testing approach. This can lead to more reliable test results and easier maintenance of test suites.
Better Bug Detection: By testing both the UI and APIs, you can identify potential issues and bugs at different levels of your application stack. This can help uncover integration issues, data validation problems, or inconsistencies between the UI and backend behavior.
Improved Test Coverage: Combining functional testing with API testing allows you to achieve higher test coverage by testing different layers of your application. This ensures that critical paths and edge cases are covered, leading to a more robust testing strategy.
In summary, these are topics where the Playwright in my opinion exceeds the capabilities of Selenium.
Selenium was a pioneer in the industry and still is useful, but in the future, I will see a bunch of projects being migrated or created from scratch using Playwright for all the advantages that it offers and taking some market share from Selenium
Playwright. (12 de February de 2024). Playwright.dev. From https://playwright.dev: https://playwright.dev/python/docs/actionability
SIgn up