Link to the full version of the project on GitHub:
Github PlaywrightUIProject
Let’s begin by introducing the Playwright library – a powerful tool for automating modern tasks on websites. Imagine it as a way to teach a computer to perform actions on a webpage all by itself. Now, let me share why I built that Java framework for testing. In the ever-evolving world of Quality Assurance (QA) Automation, where new challenges arise frequently, my framework acts as a toolbox that leverages the capabilities of Playwright. I crafted this framework to overcome specific challenges I encountered while automating web tasks.
Used:
| Playwright | TstNG | Extentreports | Page Object Model (POM) |
Familiar with Playwright? It’s akin to a digital sorcerer, powering dependable end-to-end testing for modern web applications. What distinguishes it are its superhero capabilities in contrast to other tools. Playwright doesn’t show browser bias – it collaborates seamlessly with all. And the cherry on top? It’s user-friendly, allowing you to feel like a tech pro, even without the technical prowess.
Now, let’s dive into why the Page Object Model (POM) design is a big deal. Think of POM like a blueprint for your web automation adventures. It’s a smart way to organize things so you don’t get lost in the coding maze. POM helps keep your code neat and tidy, making it easier to fix things if something goes wonky. But that’s not all – POM is like a recycling superhero. You can use the same bits of code again and again for different tasks, saving you loads of time. And hey, have you ever read a really good book? POM makes your code read like that – clear, easy to understand, and you don’t need to be a coding whiz to figure it out.
Now, let’s peek behind the curtain and see how this whole thing is put together. The architecture of my framework is like a well-organized toolbox – each tool has its place, making it easy to find what you need. I’ve set up a structure that makes sense, with folders neatly holding specific types of code.
ru.gotoqa.constants: Central repository for storing application constants, settings, and configurations.
ru.gotoqa.factory: Workshop of object creation, offering efficient instance generation and modularity.
ru.gotoqa.listeners: Platform for dynamic event monitoring and response implementation.
ru.gotoqa.pages: Library of encapsulated web page interactions, elements, and behaviors.
test.java.ru.gotoqa.tests: Hub for meticulously crafted test scenarios and validations.
Classes and packages are like different sections in a library – everything has its own category. This not only keeps things tidy but also helps me find and fix issues faster.
Now, let’s talk about the actors in our automation play – the page objects. Imagine each web page as a character with its unique traits and actions. I’ve crafted page objects to encapsulate these traits, neatly bundling interactions and elements into one convenient package.
ru.gotoqa.pages.LoginPage
ru.gotoqa.pages.MainPage
So when I need to tell the web page to do something, I just ask the right page object, and it handles all the behind-the-scenes stuff.
Testing is like following a script – you want it to be clear and easy to understand. With my framework, writing tests is a breeze. Thanks to the POM design pattern, I can focus on the exciting parts. I write tests that read like a story – each step is a clear action, and anyone reading it can follow along. And if the web page changes its lines, I only need to update that one page object, not the entire script.
/**
* MainPageTest class contains all the tests related to Main page test site
*/
public class MainPageTest extends BaseTest {
@Test
public void testHomePageTitle() {
String actualTitle = mainPage.getHomePageTitle();
Assert.assertEquals(actualTitle, AppConstants.HOME_PAGE_TITLE);
}
@Test
public void testHomePageURL() {
String actualUrl = mainPage.getHomePageURL();
Assert.assertEquals(actualUrl, properties.getProperty("url"));
}
@Test(dataProviderClass = DataProviderClass.class, dataProvider = "testDataStuffSearch")
public void testSearch(String productName) {
String actualSearchHeader = mainPage.searchForProduct(productName);
Assert.assertEquals(actualSearchHeader, "Search - " + productName);
}
}Compatibility is key, and my framework doesn’t play favorites when it comes to browsers. It’s like having a translator that speaks every language – your web tests will work seamlessly across different browsers.
In the world of Docker, the docker-compose.yaml file conducts a synchronized container performance. Docker encapsulates applications, including web browsers, in containers for consistency. Running tests within a container ensures precision and isolation. The yaml file defines container interactions, orchestrating networks and services. This setup guarantees a controlled environment, letting your tests shine in reproducible harmony.
Java ExtentReports transforms test data into vivid reports, featuring interactive dashboards, logs, and seamless integration.
And there you have it – a glimpse into the world of my Java framework with Playwright’s prowess. We’ve taken a journey through architecture, setup, interactions, and challenges. If you’re looking for a seamless way to automate web tasks, my framework might just be the missing piece in your puzzle. So go ahead, explore its nooks and crannies, and embark on your own web automation adventure.
Happy automating!
Link to the full version of the project on GitHub:
Github PlaywrightUIProject
