Session 47 - Selenium with Java | TestNG | Page Object Model Pattern

Main ideas / lessons

• Page Object Model (POM) is a design pattern (not a framework) that helps in building maintainable automation frameworks in Selenium/TestNG.
• It improves scalability by separating concerns:
  • Page Object classes: store locators (web element definitions) and action methods (ways to interact with the page).
  • Test classes: contain test methods and validations/assertions, and call action methods from page objects.
• Without POM, tests typically mix locators + actions + validations in one class, causing problems as the number of tests/pages grows.

Problems without Page Object Model

1. Duplication of locators/elements

   • The same login page locators must be re-written across multiple independent test cases (e.g., login test, search test, advanced search test).
   • With many test cases, this duplication becomes a major effort.

2. Update/maintenance issues

   • If a locator changes on a page (e.g., XPath/CSS/attribute changes), you must update it in every test where it was duplicated.

How POM solves those problems

• Create a dedicated page object class per page (e.g., LoginPage, SearchPage, AdvancedSearchPage).
• In each test:
  • Interact with only the needed page object(s).
  • Locators are defined once in the corresponding page object class, enabling reusability.
• When a page changes:
  • Update only the locator(s) in one page object class.
  • The change automatically affects all tests that reuse that page object.

Methodology / implementation approach taught (step-by-step)

A) Conceptual workflow

• Step 1: Identify all pages your application has (according to test flows).
• Step 2: For each page, create a page object class containing:
  • Locators
  • Action methods
  • No test methods and no validations
• Step 3: Create TestNG test classes containing:
  • Test methods
  • Validations/assertions
  • Use page object classes to perform actions and retrieve the outcome.

B) Creating POM page objects (2 approaches)

Approach 1: Without Page Factory (manual driver.findElement usage)

A page object class contains 3 main parts:

1. Constructor

   • Receives a WebDriver instance from the test class.
   • Stores it as a class variable so action methods can use it.

2. Locators section

   • Define locators (commonly using By), e.g.:
     • By xpath = ... (or ID/CSS/etc.)

3. Action methods section

   • Each action method:
     • Uses driver.findElement(locator).<action>()

Example actions in the video for a login page:

• setUsername(String username) → sendKeys(username)
• setPassword(String password) → sendKeys(password)
• clickLogin() → click()

SelectorHub tip (tooling):

• Use SelectorHub to generate locators quickly.
• Can generate locators in different formats; results can be copied into the locator section.

Approach 2: With Page Factory (@FindBy + PageFactory.initElements)

A page object class still contains:

1. Constructor

   • Still receives and stores WebDriver.
   • Additionally calls:
     • PageFactory.initElements(driver, this);
   • This is described as mandatory for the @FindBy fields to work.

2. Locators + element initialization using annotations

   • Use @FindBy(...) to define element fields directly as WebElement, e.g.:
     • @FindBy(xpath = "....") WebElement username;
   • The locator + element finding is handled by Page Factory.

3. Action methods

   • No findElement inside action methods anymore.
   • Action methods interact with the already-initialized WebElement, e.g.:
     • username.sendKeys(...)
     • password.sendKeys(...)
     • loginButton.click()

Extra variation mentioned:

• Alternative @FindBy syntax using how and using keywords (instead of direct xpath=...).

C) Writing the TestNG test class (example shown)

• Create a TestNG class with:

• @BeforeClass / setup():

  • Instantiate WebDriver (e.g., new ChromeDriver())
  • Configure waits (implicit wait example)
  • Navigate to the application URL
  • (Optional) maximize window

• @Test / testLogin():

  • Create the page object, passing the driver:
    • LoginPage lp = new LoginPage(driver);
  • Call action methods:
    • lp.setUsername("admin");
    • lp.setPassword("...");
    • lp.clickLogin();
  • Perform validation/assertion in the test method:
    • Example assertion: compare page title to expected value

• @AfterClass / tearDown():

  • driver.quit() or close browser

D) Running tests

• Tests can be executed:
  • Directly as TestNG tests
  • Or via a testng.xml file (video demonstrates creating an XML with the test class).

Key comparison points: Without POM vs With POM

• Without POM: locators/actions/validations in one place → duplication + harder updates.
• With POM: locators/actions separated into page objects → reuse and easier maintenance.
• Page Factory advantage (as stated):
  • Avoid calling findElement repeatedly in action methods.
  • @FindBy + PageFactory.initElements handles element lookup internally.

Speakers / sources featured

• Speaker: The video presenter/instructor (no name given in subtitles).
• Source technologies/frameworks referenced: Selenium WebDriver, TestNG, Page Object Model (POM), Page Factory (PageFactory.initElements, @FindBy), SelectorHub, WebDriver By, findElement, TestNG annotations (@BeforeClass, @Test, @AfterClass), testng.xml.