Session 49 - Selenium with Java | Hybrid Automation Framework | Page Object Model

Overview / Goal of the session

• The session starts the implementation phase of a Hybrid Automation Framework for Selenium + Java + TestNG using the Page Object Model (POM).
• Approach: design the full framework first, working incrementally:
  1. Start with 1–2 test cases
  2. Build the framework scaffolding (page objects, utilities, test base, properties/resources, etc.)
  3. After the framework is stable, add more test cases continuously
• Execution workflow described:
  • Run TestNG (test-suite XML) to generate reports/logs
  • Commit code to a local Git repository
  • Push to GitHub (remote/global)
  • Run in Jenkins in a remote environment (pipeline/CI concept)

Framework design / tech stack

• Framework type: Hybrid-driven framework
• Tech components mentioned:
  • Java
  • Selenium
  • TestNG
  • Page Object Model
• Project structure responsibilities:
  • Page objects: only page classes + elements/actions per screen
  • Test cases: test classes that call page object methods
  • testng.xml / suite XML files: orchestrate running tests and generating reports/logs
  • Utilities / test data / resources: used by tests
  • Reports / logs / screenshots / test data folders: placed at the project level

Maven setup and dependency configuration (Step 1)

• Emphasis is placed on creating a new Maven project in Eclipse for easier dependency management and reuse across environments.
• Dependencies to add to pom.xml (examples mentioned):
  • Selenium Java
  • Apache POI (Excel support)
  • Log4j (logging)
  • Apache Commons IO / Lang3
  • TestNG
  • Extent Report (reporting)
• Process guidance:
  • Create Maven project → edit pom.xml → add dependencies → update Maven project

Folder / package structure (scaffolding)

• Uses standard Maven layout but modifies it for the framework:
  • Mainly uses:
    • src/test/java for framework code (page objects, tests, utilities)
    • src/test/resources for resource files like properties/log config
  • Removes unused Maven folders (as per instructor’s current approach)
• Recommended packages under src/test/java:
  • pageObjects (POM classes)
  • testCases (TestNG test classes)
  • utilities (helper classes like Excel utilities, Extent report manager, etc.)
  • Later: testBase (shared test setup/teardown + reusable methods)
• Project-level folders (created directly under project root):
  • logs
  • reports
  • screenshots
  • testData (Excel/data files later)

Resource vs package distinction (important)

src/test/resources is for resource files (e.g., .properties, log4j config). Excel/text data should go into folders (e.g., testData), not necessarily as Java packages.

• Packages contain Java classes, while folders can contain any file types.

Page Object Model implementation (for the first test case)

Target test case

• Account Registration is chosen as the first test because it leads to login credentials for subsequent tests.

Page object classes created

1. Homepage page object

   • Contains elements:
     • My Account (link)
     • Register (link)
   • Action methods:
     • clickMyAccount()
     • clickRegister()

2. Account Registration page object

   • Contains form elements and actions:
     • first name, last name, email, phone, password, confirm password
     • privacy policy checkbox
     • continue/submit button
     • confirmation message element
   • Action methods follow naming conventions (prefix hints):
     • txt* for text boxes
     • chk* for checkboxes
     • btn* for buttons
   • No validation inside page objects:
     • getConfirmationMessage() returns the displayed message as a String only
     • Actual assertion/validation is done in the TestNG test class

Reusability via Base Page (constructor inheritance)

• Introduce a BasePage class under pageObjects:
  • Contains only the constructor setup (driver field + PageFactory initialization).
• All page object classes extend BasePage to avoid rewriting constructors repeatedly.

Test class implementation (TestNG)

Structure for the test case class

• Create a new TestNG test class under testCases:
  • Example naming: TC001_AccountRegistrationTest
• Includes methods:
  • @BeforeClass setup():
    • Initialize WebDriver (ChromeDriver mentioned)
    • Delete cookies
    • Navigate to application URL
    • Maximize window
  • @AfterClass tearDown():
    • Quit/close driver
  • @Test verify_account_registration():
    • Instantiate Homepage and AccountRegistrationPage
    • Use page object methods to:
      1. click My Account
      2. click Register
      3. fill registration form
      4. submit
      5. retrieve confirmation message
    • Assertion using TestNG Assert.assertEquals(...)

Advantage shown

• A single test method can use multiple page object classes (Homepage + Registration page).

Handling test failures with dynamic input (random test data)

Problem demonstrated

• Running the same registration test twice fails because the same email is already registered.

Solution

• Create user-defined methods to generate dynamic values at runtime:
  • Random alphabetic string (for email/local part, names)
  • Random numeric string (phone numbers)
  • Random alphanumeric with special characters (password)
• Uses Commons Lang3:
  • RandomStringUtils.randomAlphabetic(n)
  • RandomStringUtils.randomNumeric(n)
• Case formatting for names:
  • convert generated string to uppercase for first/last name via .toUpperCase()

Password generation rule

• Generate password once, store in a variable, and reuse for:
  • password
  • confirm password
• This prevents mismatch failures.

Reusability via Test Base (extract duplicated test methods)

• After the test works, instructor refactors:
  • Setup/teardown and random-data helper methods are moved into a BaseClass under the testBase package.
• Resulting pattern:
  • Each test class extends BaseClass
  • Test class contains mostly only the @Test method(s)
• Key objective: avoid duplication across test cases and centralize common logic.

Notes for next session / what’s deferred

• Logging and reporting additions are mentioned as next steps (not completed in this session).
• Excel/data-driven testing is explicitly deferred:
  • Current work uses single test data (not Excel-driven).
  • Excel will be used later for data-driven test cases.

Key speakers/sources (as stated by subtitles)

• No specific person’s name is spoken in the subtitles.
• Source indicated only by the video title:
  • “Session 49 - Selenium with Java | Hybrid Automation Framework | Page Object Model”