Skip to main content

Playwright: Locator vs ElementHandle

 In Playwright, both Locator and ElementHandle are important concepts used for interacting with elements on a web page, but they serve slightly different purposes.

Locator:
A Locator in Playwright is a way to find and interact with elements on a web page. It represents a selector that can be used to locate one or multiple elements. Once you have a Locator object, you can use it to perform actions like clicking, filling input fields, or getting the text of the element. Locators are typically used in Playwright’s page object model for cleaner and more maintainable tests.

When you perform actions using a Locator, Playwright automatically waits for the element to be present in the DOM before interacting with it. This helps in handling asynchronous content loading.

Example:



ElementHandle:
An ElementHandle in Playwright represents a handle to a DOM element on a web page. It is a reference to the actual element and provides methods to interact with the element, such as clicking, typing, or evaluating properties.

You can evaluate functions or properties within the context of an ElementHandle. This is useful for extracting data from the element.

Example:



Both Locator and ElementHandle are powerful ways in Playwright, and choosing the right one depends on your use case. Use Locator to find elements in a clean and readable way, and then interact with the matched elements using ElementHandle to perform actions, extract data, or evaluate properties. This separation of concerns enhances the readability and maintainability of your Playwright tests.

Comments

Popular posts from this blog

How to Unzip files in Selenium (Java)?

1) Using Java (Lengthy way) : Create a utility and use it:>> import java.io.BufferedOutputStream; import org.openqa.selenium.io.Zip; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOException; import java.util.zip.ZipEntry; import java.util.zip.ZipInputStream;   public class UnzipUtil {     private static final int BUFFER_SIZE = 4096;     public void unzip (String zipFilePath, String destDirectory) throws IOException {         File destDir = new File(destDirectory);         if (!destDir.exists()) {             destDir.mkdir();         }         ZipInputStream zipIn = new ZipInputStream(new FileInputStream(zipFilePath));         ZipEntry entry = zipIn.getNextEntry();         // to iterates over entries in the zip folder         while (entry != null) {             String filePath = destDirectory + File.separator + entry.getName();             if (!entry.isDirectory()) {                 extractFile (zipIn, filePath);            

Encode/Decode the variable/response using Postman itself

We get a lot of use cases where we may have to implement Base64 encoding and/or decoding while building our APIs. And, if you are wondering if it is possible to encode/decode the variable/response using Postman itself or how to encode/decode the token or password in postman and save it in a variable? To Base64 encode/decode, the quickest way is to use JavaScript methods btoa, atob: atob - It turns base64-encoded ASCII data back to binary. btoa - It turns binary data to base64-encoded ASCII. Sample code : var responseBody = pm.response.json(); var parsedPwd = JSON.parse(atob(responseBody.password)); // presuming password is in the payload pm.collectionVariables.set("password", parsedPwd);

The use of Verbose attribute in testNG or POM.xml (maven-surefire-plugin)

At times, we see some weird behavior in your testNG execution and feel that the information displayed is insufficient and would like to see more details. At other times, the output on the console is too verbose and we may want to only see the errors. This is where a verbose attribute can help you- it is used to define the amount of logging to be performed on the console. The verbosity level is 0 to 10, where 10 is most detailed. Once you set it to 10, you'll see that console output will contain information regarding the tests, methods, and listeners, etc. <suite name="Suite" thread-count="5" verbose="10"> Note* You can specify -1 and this will put TestNG in debug mode. The default level is 0. Alternatively, you can set the verbose level through attribute in "maven-surefire-plugin" in pom.xml, as shown in the image. #testNG #automationTesting #verbose # #testAutomation