Screenshots Only for Failed Tests (ITestListener)

To capture screenshots only when a test fails, use a TestNG Listener.

The commonly used interface is:

  • ITestListener

Override the:

Advertisement
  • onTestFailure()

method.

Whenever a test fails, TestNG automatically invokes this method.

Inside onTestFailure(), call your screenshot utility.

Simple Analogy

Think of it like a CCTV camera that records only when motion is detected, instead of recording continuously.

Steps Followed

Step 1: Create a Screenshot Utility

Use:

  • TakesScreenshot

to capture screenshots.

Step 2: Create a Listener Class

Implement:

 
ITestListener
 

Step 3: Override onTestFailure()

Capture the screenshot inside:

 
onTestFailure()
 

Step 4: Register the Listener

Register the listener using either:

  • testng.xml
  • @Listeners

Step 5: Store Screenshots

Save screenshots in a dedicated location.

Example:

 
/screenshots/FailedTests
 

Benefits

  • Screenshots only for failed tests
  • Cleaner reports
  • Reduced storage usage
  • Easy integration with Extent Reports
  • Easy integration with Allure Reports

STAR Answer

Situation

Screenshots were being generated for every test, making reports large and difficult to analyze.

Task

Capture screenshots only for failed test cases.

Action

Implemented an ITestListener and overrode onTestFailure() to call the screenshot utility.

Result

Reports became smaller, cleaner, and included screenshots only for failed test cases.

What Is ITestListener?

ITestListener is a TestNG interface that allows you to perform custom actions whenever test events occur.

It provides callback methods that execute automatically during the test lifecycle.

Common Callback Methods

  • onTestStart()
  • onTestSuccess()
  • onTestFailure()
  • onTestSkipped()
  • onFinish()

Registration Methods

The listener can be registered using:

  • testng.xml
  • @Listeners

Common Uses

  • Logging
  • Screenshot Capture
  • Report Enhancement
  • Custom Reporting

TestNG in the Framework: Grouping, Parallel Execution & Test Suites

Within the automation framework, TestNG acts as the execution control layer.

Grouping

Tests are organized into groups such as:

  • Smoke
  • Sanity
  • Regression

Specific groups can be executed whenever required.

Parallel Execution

TestNG supports parallel execution.

Parallel execution can be configured through:

  • testng.xml

Tests may execute in parallel at different levels, such as:

  • Methods
  • Classes
  • Tests

This significantly reduces execution time.

The same mechanism is also used for Cucumber parallel execution through a TestNG runner.

Test Suites

The:

 
testng.xml
 

file controls:

  • Test Suites
  • Test Classes
  • Test Methods
  • Include / Exclude Operations
  • Execution Order
  • Groups

Retry Logic

Retry execution is handled using:

  • RetryAnalyzer

This allows failed test cases to be re-executed automatically.

Reporting

TestNG integrates with:

  • Extent Reports
  • Allure Reports

It also generates the default:

  • Emailable Report

Framework Interview Line

"I used TestNG for execution control—grouping, parallel execution, and test suites using testng.xml. It was integrated with Maven and Jenkins as part of our CI/CD pipeline."

DataProvider & Execution Control

@DataProvider

@DataProvider is used for Data-Driven Testing.

It supplies multiple data sets to a single test method.

Each data row executes the same test once.

Priorities

Test execution order can be controlled using:

  • Priorities

testng.xml

The suite configuration file:

  • Controls execution
  • Controls grouping
  • Controls parallel execution
  • Supports execution analysis

Additional TestNG Topics (Needs Your Input)

Your DEC_Shorts.docx contains a list of 25 TestNG interview questions that currently do not have written answers.

These questions are intentionally marked as Needs Your Input instead of adding new content.

Topics include:

  • Re-running Failed Tests (testng-failed.xml)
  • Customizing Reports
  • RetryAnalyzer
  • Running Specific Groups
  • Creating a TestNG XML Suite
  • @BeforeMethod vs @BeforeClass
  • @DataProvider
  • Maven Surefire Execution
  • Parallel Execution
  • @dependsOnMethods
  • Intentionally Skipping Tests
  • SoftAssert vs HardAssert
  • Emailable Report
  • Include / Exclude in XML
  • <parameter> Parameterization
  • Jenkins Integration
  • Separate Smoke, Sanity & Regression Suites
  • IAnnotationTransformer
  • TestNG Not Detecting Test Methods
  • Optimizing Large Test Suites (500+ Test Cases)

Several of these topics are already partially covered within your existing framework tutorials and can later be expanded using your own content.

FAQs

How Do You Capture Screenshots Only for Failed Test Cases?

Use ITestListener.

Override:

 
onTestFailure()
 

Call a screenshot utility built using:

 
TakesScreenshot
 

Register the listener using:

  • testng.xml
  • @Listeners

Store screenshots inside a dedicated failure folder.

What Is ITestListener?

ITestListener is a TestNG interface that provides callback methods for different test events.

Common methods include:

  • onTestStart()
  • onTestSuccess()
  • onTestFailure()
  • onTestSkipped()
  • onFinish()

It is commonly used for:

  • Logging
  • Screenshot Capture
  • Custom Reports

How Do You Run a Specific Group of Tests?

Assign tests to groups such as:

  • Smoke
  • Sanity
  • Regression

Run the required group using:

  • testng.xml
  • TestNG Run Configuration

How Do You Run Tests in Parallel?

Configure parallel execution inside:

 
testng.xml
 

Supported execution levels include:

  • Methods
  • Classes
  • Tests

Parallel execution is also commonly used for Cucumber through a TestNG runner.

What Is @DataProvider Used For?

@DataProvider supplies multiple datasets to a test method.

Each dataset executes the same test once, enabling Data-Driven Testing.