Session 50: Selenium with Java | Hybrid Framework | Logs, Properties, Cross Browser

Main ideas / lessons from the session

• The session continues building a Selenium + Java hybrid framework, building on the previous class where the basic folder structure, page objects, and a registration test case were already implemented.
• Today’s key focus is adding four framework capabilities:
  1. Logging (Log4j2) to capture automation + (optionally) deeper network/application logs
  2. Cross-browser + parallel testing using TestNG XML parameterization
  3. Reading common test data from a properties file (config.properties)
  4. Reinforcing a step-by-step implementation workflow (don’t move to the next step until the current one works)

---

1) Logging in the framework (Log4j2)

What “logging” means

• Logging = recording events as text (e.g., “launching application”, “clicking register”, “providing details”, “validation”, “test failed”).
• Logs are written to files so they can be reviewed later (especially when UI-only debugging isn’t enough).

Why logging is useful

• In production (application logs): helps track unauthorized or problematic actions and provides security/traceability.
• In automation (automation logs):
  • If a test fails, the log file helps analyze defects without relying only on UI steps/screenshots.
  • Helps diagnose issues that may reproduce differently across environments.

Log types / levels discussed

• The session lists 6 main log levels (Trace, Debug, Info, Warn/Warning, Error, Fatal) plus configuration options:
  • Trace
  • Debug
  • Info
  • Warning
  • Error
  • Fatal
  • Configuration values:
    • off = no log messages
    • all = all log types

How log levels affect output

• Setting a higher threshold includes lower levels as well:
  • Example: if level = debug, you get logs from debug downwards (including info/warn/error/fatal).
• For this automation framework:
  • Default focus is typically Info logs (human-readable messages written in tests).
  • Debug logs are more detailed (including more internal/network-like activity), mainly for deeper diagnosis.

Log4j2 architecture concepts: Appenders and Loggers

• Appender: decides where logs are written
  • Console
  • File (prefer file for permanent storage + easier sharing)
• Logger: decides what level of logs is produced
  • Example: whether you generate Info-only vs Debug+Info+…

Required setup steps (detailed)

Step A: Add Log4j2 dependencies

• Add dependencies in the Maven pom.xml
• Uses Log4j2 libraries (core + API), with a suggested stable version 2.23.1.

Step B: Create/Place configuration file

• Add log4j2.xml into:
  • src/test/resources/
• Important:
  • Do not change the filename (log4j2.xml must match for auto-loading)

Configuration structure

• <appenders>
  • console appender
  • rolling file appender (used most of the time)
• <loggers>
  • chooses log level (e.g., info vs debug)
  • links logger to the appender(s) (file/console/both)

Rolling file behavior

• Uses a base path like ./logs
• Writes to something like automation.log plus timestamped rollover files
• Rollover happens when file size is exceeded

Step C: Update Base Class to initialize Log4j2

• In the base class setup method, create a logger instance:
  • Logger logger = LogManager.getLogger(this.getClass());
• Purpose: ensures log4j2.xml is loaded and the logger is available for all tests.

Step D: Add log statements in each test

• Use the logger at key points in the test, e.g.:
  • logger.info("starting registration test case ...");
  • logger.info("clicked on register link");
  • logger.info("providing customer details");
  • logger.info("validating expected message");

Failure logging with try/catch

• In catch:
  • logger.error("test failed");
  • optionally logger.debug(...)
  • fail the test (e.g., Assert.fail(...))

Debug behavior note

• Debug logs appear only if:
  • the XML log level enables Debug, and
  • the test code explicitly calls logger.debug(...)

How log output is expected to behave during runs

• By default, Info logs appear in the log file when XML is set to Info.
• On failure:
  • catch block can generate Error/Fatal logs
  • Debug logs appear only if enabled
• Rolling file:
  • when file size threshold is reached, old logs are timestamped and a new log file starts
• Logs persist across runs:
  • old logs are preserved in timestamped backup files unless deleted

---

2) Cross-browser + parallel execution with TestNG XML

Core method described

• Create TestNG XML files to:
  • list test cases/suites
  • pass parameters like browser name
  • optionally pass OS name (for future grid use)
• In the framework, parameters are received in the base class before/under @BeforeClass setup and used to decide which WebDriver to launch.

Step-by-step instructions (detailed)

Step 1: Create a master suite XML

• Create XML at the project level (not inside test packages)
• Example: master.xml
• Add parameters before <test> / <classes>:
  • OS = Windows (or other OS later)
  • browser = Chrome (example)

Step 2: Modify Base Class setup to accept parameters

• Use TestNG annotations (mentioned as before-class style) to receive:
  • String OS
  • String browser
• Add a switch (or equivalent conditional) to launch different browsers:
  • Chrome -> Chrome driver
  • Edge -> Edge driver
  • Firefox -> Firefox driver
  • default:
    • print “invalid browser name”
    • return to stop execution if invalid
• Normalize case:
  • convert the browser parameter to lowercase to avoid mismatch

Step 3: Create a separate XML for cross-browser parallel runs

• Make another XML copy, e.g. crossBrowserTesting.xml
• Add multiple <test> entries:
  • one for Chrome
  • one for Edge
  • one for Firefox
• Enable parallel execution using:
  • parallel="tests" (as stated)
• Configure thread-count guidance:
  • keep thread count small (roughly 2–5) to avoid instability

Expected behavior

• Serial execution: tests run one after another.
• Parallel execution: Chrome/Edge/Firefox start together and complete in parallel.
• Logs continue to be written to the same logging system (per the described setup).

---

3) Reading common values from a config properties file

Purpose

• Avoid hardcoding common values (URL, username/email, password, product names) across many tests.
• Store shared values in one place and load them at runtime.

Step-by-step instructions (detailed)

Step 1: Create a properties file

• Add config.properties under:
  • src/test/resources/
• Store key-value pairs like:
  • appURL, appURL1, email, password, searchProductName, etc.

Step 2: Load the properties in Base Class setup

• Add a Properties object (e.g., public Properties p;)
• Read file using an input stream from:
  • src/test/resources/config.properties
• Load into p using p.load(...)

Step 3: Replace hardcoded values in tests

• Use:
  • p.getProperty("appURL"), p.getProperty("email"), etc.
• This makes all tests automatically use the shared config.

Expected outcome

• When running via TestNG XML, tests should pick up the environment’s URL (and other values) from config.properties rather than hardcoded strings.

---

Implementation workflow guidance given

• Follow the session’s recommended order:
  1. Ensure logging works
  2. Then implement cross-browser/parallel
  3. Then add the properties/config file approach
• Don’t jump ahead:
  • only proceed to the next framework step if the current step is functioning correctly.

---

Speakers / sources featured

• No explicit speaker name is provided in the subtitles.
• Source mentioned: Apache (Log4j2 website/templates; also references Apache POI analogy and Apache Log4j2 documentation).