Video summary

Session 46 - Selenium with Java | TestNG | Listeners | Extent Report Generation

Main summary

Key takeaways

Educational

Main ideas / lessons

  • TestNG statuses: When running TestNG tests, each test method can end in one of three outcomes:

    • Passed
    • Failed
    • Skipped

  • Post-actions concept:

    • After a test method finishes and yields a status (pass/fail/skip), you may want to perform actions based on that status.
    • These status-driven actions are called post actions.
    • Examples:
      • If a test passes → update results in a report.
      • If a test fails → capture a screenshot and record failure + screenshot in the report.
      • If a test is skipped → record the skipped status in the report.

  • TestNG Listeners as the mechanism:

    • Listeners are used to implement these post-actions by responding automatically to TestNG lifecycle events.
    • Listener methods trigger without manually calling them—TestNG calls them during execution.

  • Core lifecycle listener methods (commonly used):

    • onStart (once at the beginning of the whole run)
    • onTestStart (before each individual test method)
    • onTestSuccess (when a test method passes)
    • onTestFailure (when a test method fails)
    • onTestSkipped (when a test method is skipped)
    • onFinish (once at the end of the whole run)

Implementation methodology / step-by-step instructions

A) Implement TestNG listeners (3-step approach)

  1. Step 1: Create a test case with multiple test methods

    • A single TestNG class can contain multiple @Test methods.
    • Example behaviors:
      • One test designed to pass
      • One test intentionally designed to fail (e.g., invalid URL)
      • One test becomes skipped due to dependency (e.g., dependsOnMethods)

  2. Step 2: Create a listener class

    • Create a new Java class to act as the listener (name can be anything).
    • Implement listeners using one of these approaches:
      • Implement ITestListener directly, OR
      • Extend TestListenerAdapter
    • The approach used in the video: implement ITestListener.
    • You must implement the predefined method names exactly as in ITestListener.
    • Note: lecturer mentions methods should be public when implementing.

  3. Step 3: Integrate the test + listener using an XML file

    • Create/modify a testng.xml that includes:
      • The test class
      • The listener class under a separate XML section:
        • Add a <listeners> tag
        • Inside it, add <listener class-name="..."> pointing to the listener
    • Listener methods will then trigger automatically during suite execution.

B) Alternative listener integration (annotation-based; not preferred)

  • Instead of testng.xml, you can attach the listener directly to a test class using:
    • @Listeners(MyListenerClass.class)
  • Why the XML approach is preferred (per lecturer):
    • If you have many test classes, XML lets you configure the listener in one place.
    • Using annotations would require adding the listener entry to every test class.

How Extent Reports fits into this

  • Extent Reports is described as a third-party reporting library commonly used with Selenium/Java.

  • TestNG’s default reports are considered less detailed/less attractive.

  • Why listeners are needed for Extent Reports:

    • Report creation and updates are treated as post actions.
    • Those should occur after the test execution status is known:
      • Initialize report UI/template at the beginning
      • Update each test entry on pass/fail/skip
      • Flush/write report at the end

Extent Reports implementation structure (as taught)

A) Dependencies

  • Add required Maven dependencies, including:
    • Extent Reports library
    • (The video also mentions other dependencies such as Selenium, Apache POI, Log4j to avoid warnings)

B) Use an Extent Report “manager” listener class

  • Create a listener class (e.g., ExtentReportManager) that implements ITestListener.

  • The video emphasizes Extent Reports relies conceptually on three main Extent classes:

    • ExtentSparkReporter

      • Responsible for UI/theme and where/how the report is displayed.
      • Handles look-and-feel (e.g., dark vs standard), document title/name, report file location.

    • ExtentReports

      • Responsible for common metadata on the report.
      • Examples mentioned:
        • tester name
        • environment/OS
        • browser
        • project/module name
        • computer/host name

    • ExtentTest

      • Responsible for per-test status updates:
        • create a test entry
        • mark as PASS/FAIL/SKIP
        • log failure messages/errors
        • (future improvement mentioned) attach screenshots

C) Where to do which logic inside listener methods

  • onStart

    • Create report template + UI (ExtentSparkReporter config)
    • Attach reporter to ExtentReports
    • Populate system/common info via extent.setSystemInfo(key, value)

  • onTestSuccess

    • Create/update a test entry using the test method name from the result
    • Log status as PASS

  • onTestFailure

    • Create/update a test entry with the test name
    • Log status as FAIL
    • Capture/log error message using result.getThrowable()
    • (Improvement mentioned later: also attach failure screenshot)

  • onTestSkipped

    • Create/update a test entry with the test name
    • Log status as SKIP

  • onFinish

    • Call extent.flush() to finalize and write the report to disk

D) Running and where the report appears

  • The report is generated in a specified folder path (e.g., a reports directory).
  • The HTML report name is configured (initially hardcoded in the simplified example).
  • You may need to refresh the report in the browser to see latest updates.

Limitations of the “basic” Extent utility shown (and what the full framework will improve)

  • Hardcoded report file name

    • Causes old reports to be overwritten.
    • Suggested improvement: include a timestamp in the report name to preserve history.

  • Hardcoded system/common info

    • Suggested improvement: fetch values dynamically at runtime (computer name, OS, browser, environment, etc.).

  • No screenshot on failure in the simplified example

    • Suggested improvement: capture and attach screenshot for failed tests.

  • Report shows only method-level info

    • Suggested improvement: show test case/class identifiers (easier to understand which class/test case a method belongs to, especially when many classes exist).

Speakers / sources featured

  • Speaker: Unspecified (video lecturer/instructor; no name provided in the subtitles)
  • Primary sources referenced/documentation:
    • TestNG official documentation (for ITestListener / listeners and lifecycle methods)
    • Extent Reports official documentation (for setup and usage; Maven dependency info)
  • Technologies referenced:
    • TestNG
    • Selenium WebDriver
    • Apache POI (Excel; explicitly stated as unrelated to Extent/TestNG listeners)
    • Log4j (mentioned to avoid console warnings)
    • Maven repositories (to fetch Extent Reports dependency)

Original video