📁 Project Structure Overview

This is a modular TestNG-based hybrid automation framework following Page Object Model (POM) structure with utilities, logging, listeners, and screenshot features.

🔸 1. src/main/java – Core Framework

📦 base

• BaseTest.java: Common setup/teardown logic using WebDriver, @BeforeMethod, and @AfterMethod.

📦 factory

• DriverFactory.java: WebDriver creation logic, supports multiple browsers.

📦 listeners

• ReportListeners.java: Implements ITestListener, captures events like onTestSuccess, onTestFailure, etc.

📦 pages

• LoginPage.java, ProductsPage.java: Follows Page Object Model, encapsulates locators and actions.

📦 utilities

• ConfigReader.java: Reads data from .properties files.
• ScreenshotUtil.java: Captures screenshots on failure.
• WaitUtil.java: Reusable WebDriverWait methods.

🔸 2. src/test/java – Test Code

• LoginTest.java, LogoutTest.java: Contains actual @Test methods using page classes.

🔸 3. src/test/resources – Configuration

• DEV-config.properties, QA-config.properties: Environment-specific configs (URL, credentials).
• log4j2.properties: Logging configuration file for Log4j2.

🔸 4. logs/automation.log

Log file generated during test execution.

🔸 5. screenshots/

Screenshots automatically captured on test failure. Example:

Screenshot_testLoginWithLockedCredentials_20072025_134120.png

🔸 6. testng.xml

TestNG suite file for organizing test execution. Example:

<suite name="Regression Suite">
  <test name="Login Tests">
    <classes>
      <class name="tests.LoginTest"/>
    </classes>
  </test>
</suite>

🔸 7. pom.xml

Maven file used for dependency management (Selenium, TestNG, Log4j, etc.).

✅ Key Features

Feature	Description
Page Object Model (POM)	Improves modularity and maintainability
TestNG	Powerful test execution framework
Listeners	Captures test lifecycle events
Screenshot Capture	Takes screenshots on test failure
Log4j Logging	Logs test flow and issues
Environment Config	Supports DEV/QA environments
Maven	Manages dependencies and builds

📝 Advantages

• Highly modular and reusable
• Screenshot and log-based debugging
• Easy to integrate with Jenkins or CI tools
• Supports parallel test execution via TestNG


Page Object Model (POM) in Test Automation – A Detailed Guide

The Page Object Model (POM) is one of the most widely used design patterns in test automation. It helps automation engineers write clean, maintainable, and scalable test code. This article explains POM in a detailed and beginner-friendly way, with real-world examples.

Introduction

As automation projects grow, maintaining test scripts becomes increasingly difficult. UI changes, duplicated locators, and tightly coupled test logic often lead to fragile test suites. The Page Object Model was introduced to solve these problems by separating test logic from UI interaction logic.

What is Page Object Model (POM)?

Page Object Model is a design pattern where each web page of an application is represented by a separate class. This class contains the web elements and methods that interact with those elements. Test classes do not directly access web elements; instead, they use methods defined in page classes.

Why Do We Need Page Object Model?

Without POM, locators are spread across test cases, making maintenance difficult when UI changes. With POM, all locators are stored in one place, reducing duplication and improving readability. It also allows multiple test cases to reuse the same page logic, saving time and effort.

Core Concept of Page Object Model Architecture

POM follows a layered architecture where responsibilities are clearly divided. Each layer has a specific purpose, making the framework easier to understand and scale.

Page Layer (Page Classes)

The Page Layer contains page classes that represent application screens. Each page class stores web element locators and methods that perform actions such as clicking, entering text, or navigating to another page. No assertions or test validations are written here.

Test Layer (Test Classes)

The Test Layer contains test classes that define test scenarios and validations. These classes call methods from page classes and perform assertions to verify expected behavior. This keeps test cases clean and focused on business logic.

Base / Utility Layer

The Base or Utility Layer manages common functionality such as browser initialization, driver management, waits, configuration handling, and teardown operations. This avoids repetition and centralizes reusable logic.

Key Principles of Page Object Model

One Page Equals One Class

Each web page or major component should have its own page class. This ensures clarity and makes it easy to identify where page-related changes should be made.

Encapsulation of Web Elements

Web elements should be private and accessed only through public methods. This hides implementation details and protects test logic from UI changes.

No Assertions in Page Classes

Assertions belong in test classes, not page classes. Keeping assertions out of page classes ensures that pages remain reusable across multiple tests.

Reusability of Page Methods

Page methods should represent user actions rather than test steps. Well-designed methods can be reused across different test scenarios.

Advantages of Page Object Model

The Page Object Model improves maintainability, reduces code duplication, enhances readability, and makes automation frameworks scalable. It also simplifies collaboration between team members.

Common Mistakes While Implementing POM

Common mistakes include adding assertions inside page classes, hardcoding test data, exposing web elements as public, and combining multiple pages into a single class. Avoiding these mistakes ensures a clean POM implementation.

Page Object Model with PageFactory vs Without PageFactory

POM with PageFactory

Using PageFactory allows elements to be defined using annotations such as @FindBy. This results in cleaner code and lazy initialization of web elements. It is beginner-friendly and commonly used in Selenium frameworks.

POM without PageFactory

Without PageFactory, elements are located using driver.findElement methods. This approach provides more control but can be more verbose. Both approaches are valid depending on project requirements.

Real-World Usage of Page Object Model

In real-world projects, POM is often combined with TestNG or JUnit, Cucumber for BDD, Maven or Gradle for build management, and CI/CD pipelines for continuous testing. This combination results in robust and professional automation frameworks.

Conclusion

The Page Object Model is a foundational concept in automation testing. By separating test logic from UI logic, it enables teams to build stable, maintainable, and scalable test suites. Mastering POM is essential for any automation engineer working with Selenium.