TestNG Reports Generation in Selenium: How to Generate?

โšก Smart Summary

TestNG Reports are the default HTML result files that TestNG writes into the test-output folder after every run, showing which test cases passed, failed or were skipped, plus any Reporter logs.

  • ๐Ÿ”˜ Default output: Every TestNG run creates a test-output folder without any extra code.
  • โ˜‘๏ธ Two HTML views: emailable-report.html summarises results, index.html links to the detailed views.
  • โœ… Reporter logs: Reporter.log() writes custom messages straight into the generated report.
  • ๐Ÿงช Suite runs: Running testng.xml groups several classes into one consolidated report.
  • ๐Ÿ› ๏ธ Customisation: ITestListener and IReporter let a team build its own report format.
  • ๐Ÿ“Š Beyond defaults: ExtentReports and Allure add charts, history and screenshot attachments.

TestNG reports generation in Selenium

What are TestNG Reports?

TestNG Reports are the default HTML reports which are generated once the test cases are executed using TestNG. These reports help you to identify the information about test cases and the status of a project. TestNG reports in Selenium record three outcomes for every test method โ€” pass, fail and skip โ€” so you can check the data about test cases at a glance.

Report generation is very important when you are doing the Automation Testing as well as for Manual Testing.

  • By looking at the result, you can easily identify how many test cases are passed, failed and skipped.
  • By looking at the report, you will come to know what the status of the project is.

Selenium WebDriver is used for automating the web application, but it does not generate any reports on its own.

  • The TestNG will generate the default report.
  • When you execute the testng.xml file and refresh the project, you will get a test-output folder, and that folder holds the reporting output from TestNG.
  • Right click on the emailable-report.html and select the option Open with the web browser.

Note: the behaviour described here is unchanged in TestNG 7.x. Releases from TestNG 7.6 onward require JDK 11 or higher, so an older project may need its JDK level raised before the reports are produced.

Types of TestNG Reports in the test-output Folder

Before opening any single file, it helps to know what the test-output folder actually contains. TestNG writes several artefacts on every run, and each one answers a different question.

File or folder What it holds When it is useful
index.html The landing report that links to the results, groups, times and reporter output views. Digging into one run in detail.
emailable-report.html A single self-contained page summarising passed, failed and skipped methods per class. Sharing a result with people who are not opening the project.
testng-results.xml The machine-readable XML written by the built-in XML reporter, with per-method status and duration. Feeding a dashboard or a custom parser.
junitreports JUnit-format XML files, one per test class. Any CI plug-in that reads the JUnit result format.
testng-failed.xml A generated suite file that lists only the methods that failed. Re-running just the failures instead of the whole suite.

The two HTML files are the ones this tutorial opens next, so the walkthrough below starts with emailable-report.html.

How to generate reports in Selenium

Method-1: emailable-report.html

  1. Click on option โ€œemailable-report.htmlโ€
  2. Click on option web browser

The screenshot below shows the emailable-report.html file being opened from the test-output folder.

Selecting emailable-report.html inside the TestNG test-output folder

The output reports in TestNG reporting will look like below if both the classes are passed:

TestNG emailable report showing DemoA and DemoB test classes passed

Consider the scenario in where you are intentionally failing the test case i.e. DemoB class. Then convert both the classes into testng.xml suite file and run it. Then the result will look like this. It will show the failed test cases.

This is result for DemoB class:

Emailable report highlighting the intentionally failed DemoB test case

Similarly, result for the Class DemoA will look like this:

Emailable report summary row for the passing DemoA class

Method-2: index.html

  1. Right click on the index.html from the project directory.
  2. Select option open with web browser option. It will display the result in the following order.

The screenshot below shows index.html being opened from the project directory.

Opening index.html from the project directory in a web browser

The result will look like this:

TestNG index.html report landing page listing the run result views

Method-3: Reporter Class

Along with these TestNG report generated methods, you can use object.properties file to store the system generated logs as well as user generated logs. But one of the simplest ways to store log information in testing is using Reporter Class.

Reporter.log in Selenium is a class present in TestNG for Selenium reporting. It provides 4 different methods to store log information they are:

  1. Reporter.log(String s);
  2. Reporter.log(String s, Boolean logToStandardOut);
  3. Reporter.log(String s, int level);
  4. Reporter.log(String s, int level, Boolean logToStandardOut);

The second argument decides whether the message is echoed to the console as well as the report, and the level argument controls the verbosity at which the message is kept.

Example:

Create Two classes such as DemoA and DemoB and write the following code inside the classes.

For Class DemoA;

  • The Code for DemoA is already explained above. Here you are using log method of Reporter class. (For implementing a reporting class of your own, the class has to implement the org.testng.IReporter interface.)
  • The log method is a static method of Reporter class. So you are accessing that method through the Reporter class.
  • The log method is used to store log information that is written inside the program. By looking at the log information, you will easily come to know where exactly the execution of the program is stopped.

The screenshot below shows the Reporter.log calls placed inside the DemoA class.

Reporter.log statements written inside the DemoA test class

For Class DemoB:

Reporter.log statements written inside the DemoB test class

  • Now, Create testng.xml file by selecting these two classes and
  • Select run as and
  • Click on the convert to testng.
  • Then run this testng.xml file by selecting run as and select testng suite.
  • Then refresh the project open the test-output folder.
  1. In the test-output folder, open the emailable-report.html. It will look like:

    Emailable report produced after running the DemoA and DemoB testng.xml suite

    Similarly, you will have an Output for Demo B project as well.

  2. In the test-output folder, open the index.html. It will look like:

    index.html report produced after the testng.xml suite run

Click on reporter output. It will open logging info whatever written in the test methods.

TestNG reporter output view listing the messages logged by the test methods

Click on the Times. It will going to show how much time it took to run the test method present in class using TestNG reporting tools.

TestNG Times view showing how long each test method took to run

How to Customize TestNG Reports with ITestListener and IReporter

The three methods above use whatever TestNG produces by default. When a team needs a different layout, extra fields or a live progress view, TestNG exposes two extension points rather than asking you to patch the default report.

  • ITestListener is notified in real time, as each test starts, passes, fails or is skipped. Use it when the information has to be captured at the moment the event happens โ€” a screenshot on failure, for example.
  • IReporter is notified once, after every suite has finished, and receives objects describing the whole run. Use it when the output is a finished document, such as a PDF or a custom HTML page.

A listener that pushes each outcome into the report through the Reporter class looks like this.

import org.testng.ITestListener;
import org.testng.ITestResult;
import org.testng.Reporter;

public class ReportListener implements ITestListener {

    @Override
    public void onTestSuccess(ITestResult result) {
        Reporter.log("PASSED: " + result.getName(), true);
    }

    @Override
    public void onTestFailure(ITestResult result) {
        Reporter.log("FAILED: " + result.getName(), true);
    }

    @Override
    public void onTestSkipped(ITestResult result) {
        Reporter.log("SKIPPED: " + result.getName(), true);
    }
}

Registering the listener is done in the same testng.xml suite file that you already created for DemoA and DemoB.

<suite name="Demo Suite">
  <listeners>
    <listener class-name="ReportListener" />
  </listeners>
  <test name="Demo Test">
    <classes>
      <class name="DemoA" />
      <class name="DemoB" />
    </classes>
  </test>
</suite>

Two command-line switches are worth knowing while you experiment. The -d option changes the directory the reports are written to, and -usedefaultlisteners false switches the built-in reporters off so that only your own listener runs. Both are described in the official TestNG logging and results documentation, which also documents the properties accepted by the built-in XML reporter.

A listener is registered once and then applies to every class in the suite, which is why teams that run large automation testing suites usually prefer it over adding log lines to each test method by hand.

TestNG Default Reports vs ExtentReports vs Allure

The default reports are enough for a small suite, but they carry no history and no charts. Two open-source libraries are commonly bolted on when a suite grows, and both work with TestNG.

Capability TestNG default ExtentReports Allure Report
Setup effort None โ€” produced automatically Add the library and write the reporter code Add the adapter, then generate the report from results
Charts and dashboards No Yes Yes
Screenshots Only through Reporter.log markup Built-in attachment API Built-in attachment API
Run history and trends No Through the optional server component Yes, from stored previous results
Framework coverage TestNG only Java and .NET Framework agnostic

Start with the default reports while the suite is small. Move to ExtentReports when stakeholders ask for readable dashboards, and to Allure Report when flaky-test history across builds becomes the question that matters. Whichever you pick, the report is normally published by the build job, which is covered in the Jenkins continuous integration tutorial.

FAQs

The folder appears only after TestNG finishes a run and the project is refreshed in the IDE. An empty folder usually means the class was launched as a plain Java application, or the default listeners were switched off, so no reporter ever ran.

Yes. TestNG writes to test-output by default. Pass the -d option on the command line, or set the output directory in the IDE run configuration or in the Maven Surefire settings that launch the suite.

Capture the image inside a listener method such as onTestFailure, save the file beside the report, then write an HTML image tag through Reporter.log. The report renders the markup, so the picture appears next to the failed method.

TestNG itself does not send mail. Teams normally attach emailable-report.html from a build job, for example a Jenkins post-build email step, or add a small mail routine inside an IReporter implementation.

AI models group failures by stack-trace similarity, separate genuine defects from environment or timing failures, and rank which failing methods to inspect first. A long emailable-report list becomes a short prioritised queue for the team.

GitHub Copilot can scaffold listener classes, Reporter.log statements and testng.xml entries from a short comment. Review every suggestion, because generated listeners often miss the exact interface methods TestNG expects.

Once an IRetryAnalyzer is attached, each retry is recorded alongside the final outcome. The default report therefore shows every attempt, so an unstable test can appear as both a failure and a pass in the same run.

Pass -usedefaultlisteners false on the command line, or set useDefaultListeners to false in the Maven Surefire or Ant configuration. Only the reporters you register explicitly then run, which shortens the run for very large suites.

Summarize this post with: