Logging and results

The results of the test run are created in a file called index.html in the directory specified when launching SuiteRunner.This file points to various other HTML and text files that contain the result of the entire test run.

It’s very easy to generate your own reports with TestNG with Listeners and Reporters:

  • Listeners implement the interface {javadocs-base-url}/org/testng/ITestListener.html[org.testng.ITestListener] and are notified in real time of when a test starts, passes, fails, etc…​

  • Reporters implement the interface {javadocs-base-url}/org/testng/IReporter.html[org.testng.IReporter] and are notified when all the suites have been run by TestNG.The IReporter instance receives a list of objects that describe the entire test run.

For example, if you want to generate a PDF report of your test run, you don’t need to be notified in real time of the test run so you should probably use an IReporter.If you’d like to write a real-time reporting of your tests, such as a GUI with a progress bar or a text reporter displaying dots (".") as each test is invoked (as is explained below), ITestListener is your best choice.

Logging Listeners

Here is a listener that displays a "." for each passed test, a "F" for each failure and a "S" for each skip:

public class DotTestListener extends TestListenerAdapter {
  private int m_count = 0;

  @Override
  public void onTestFailure(ITestResult tr) {
    log("F");
  }

  @Override
  public void onTestSkipped(ITestResult tr) {
    log("S");
  }

  @Override
  public void onTestSuccess(ITestResult tr) {
    log(".");
  }

  private void log(String string) {
    System.out.print(string);
    if (++m_count % 40 == 0) {
      System.out.println(" ");
    }
  }
}

In this example, I chose to extend {javadocs-base-url}/org/testng/TestListenerAdapter.html[TestListenerAdapter], which implements {javadocs-base-url}/org/testng/ITestListener.html[ITestListener] with empty methods, so I don’t have to override other methods from the interface that I have no interest in. You can implement the interface directly if you prefer.

Here is how I invoke TestNG to use this new listener:

java -classpath testng.jar;%CLASSPATH% org.testng.TestNG -listener org.testng.reporters.DotTestListener test\testng.xml

and the output:

........................................
........................................
........................................
........................................
........................................
.........................
===============================================
Total tests run: 226, Failures: 0, Skips: 0
===============================================
When you use -listener, TestNG will automatically determine the type of listener you want to use.

Logging Reporters

The org.testng.IReporter interface only has one method:

public void generateReport(List<ISuite> suites, String outputDirectory);

This method will be invoked by TestNG when all the suites have been run and you can inspect its parameters to access all the information on the run that was just completed.

JUnit Reports

TestNG contains a listener that takes the TestNG results and outputs an XML file that can then be fed to JUnitReport (below is an example of the junitreport ant task.

<target name="reports">
  <junitreport todir="test-report">
    <fileset dir="test-output">
      <include name="*/*.xml"/>
    </fileset>

    <report format="noframes"  todir="test-report"/>
  </junitreport>
</target>

Reporter API

If you need to log messages that should appear in the generated HTML reports, you can use the class {javadocs-base-url}/org/testng/Reporter.html[org.testng.Reporter] :

Reporter.log("M3 WAS CALLED");
show output1
show output2

XML Reports

TestNG offers an XML reporter capturing TestNG specific information that is not available in JUnit reports. This is particularly useful when the user’s test environment needs to consume XML results with TestNG-specific data that the JUnit format can’t provide. This reporter can be injected into TestNG via the command line with -reporter.

Here’s a sample usage:

-reporter org.testng.reporters.XMLReporter:generateTestResultAttributes=true,generateGroupsAttribute=true

The full set of options that can be passed is detailed in the below table. Make sure to use :

  • : - to separate the reporter name from its properties

  • = - to separate key/value pairs for properties

  • , - to separate multiple key/value pairs

Below is a sample of the output of such a reporter:

<testng-results>
    <suite name="Suite1">
        <groups>
            <group name="group1">
                <method signature="com.test.TestOne.test2()" name="test2" class="com.test.TestOne"/>
                <method signature="com.test.TestOne.test1()" name="test1" class="com.test.TestOne"/>
            </group>
            <group name="group2">
                <method signature="com.test.TestOne.test2()" name="test2" class="com.test.TestOne"/>
            </group>
        </groups>
        <test name="test1">
            <class name="com.test.TestOne">
                <test-method status="FAIL" signature="test1()" name="test1" duration-ms="0"
                             started-at="2007-05-28T12:14:37Z" description="someDescription2"
                             finished-at="2007-05-28T12:14:37Z">
                    <exception class="java.lang.AssertionError">
                        <short-stacktrace>
                            <![CDATA[
                java.lang.AssertionError
                ... Removed 22 stack frames
              ]]>
                        </short-stacktrace>
                    </exception>
                </test-method>
                <test-method status="PASS" signature="test2()" name="test2" duration-ms="0"
                             started-at="2007-05-28T12:14:37Z" description="someDescription1"
                             finished-at="2007-05-28T12:14:37Z">
                </test-method>
                <test-method status="PASS" signature="setUp()" name="setUp" is-config="true" duration-ms="15"
                             started-at="2007-05-28T12:14:37Z" finished-at="2007-05-28T12:14:37Z">
                </test-method>
            </class>
        </test>
    </suite>
</testng-results>

This reporter is injected along with the other default listeners so you can get this type of output by default. The listener provides some properties that can tweak the reporter to fit your needs. The following table contains a list of these properties with a short explanation:

Property Comment Default Value

outputDirectory

A String indicating the directory where should the XML files be output.

The TestNG output directory

timestampFormat

Specifies the format of date fields that are generated by this reporter

yyyy-MM-dd’T’HH:mm:ss’Z'

fileFragmentationLevel

An integer having the values 1, 2 or 3, indicating the way that the XML files are generated:

  • 1 - will generate all the results in one file.

  • 2 - each suite is generated in a separate XML file that is linked to the main file.

  • 3 - same as 2 plus separate files for test-cases that are referenced from the suite files.

1

splitClassAndPackageNames

This boolean specifies the way that class names are generated for the <class> element. For example, * you will get <class class="com.test.MyTest"> for` false and * <class class="MyTest" package="com.test"> for true.

false

generateGroupsAttribute

A boolean indicating if a groups attribute should be generated for the <test-method> element. This feature aims at providing a straight-forward method of retrieving the groups that include a test method without having to surf through the <group> elements.

false

generateTestResultAttributes

A boolean indicating if an <attributes> tag should be generated for each <test-method> element, containing the test result attributes (See ITestResult.setAttribute() about setting test result attributes). Each attribute toString() representation will be written in a <attribute name="[attribute name]"> tag.

false

stackTraceOutputMethod

Specifies the type of stack trace that is to be generated for exceptions and has the following values:

  • 0 - no stacktrace (just Exception class and message).

  • 1 - a short version of the stack trace keeping just a few lines from the top

  • 2 - the complete stacktrace with all the inner exceptions

  • 3 - both short and long stacktrace

2

generateDependsOnMethods

Use this attribute to enable/disable the generation of a depends-on-methods attribute for the <test-method> element.

true

generateDependsOnGroups

Enable/disable the generation of a depends-on-groups attribute for the <test-method> element.

true

In order to configure this reporter you can use the -reporter option in the command line or the Ant task with the nested <reporter> element. For each of these you must specify the class org.testng.reporters.XMLReporter. Please note that you cannot configure the built-in reporter because this one will only use default settings. If you need just the XML report with custom settings you will have to add it manually with one of the two methods and disable the default listeners.

TestNG Exit Codes

When TestNG completes execution, it exits with a return code. This return code can be inspected to get an idea on the nature of failures (if there were any). The following table summarises the different exit codes that TestNG currently uses.

FailedWithinSuccess Skipped Failed Status Code Remarks

Column 1, row 1

Column 2, row 1

Column 3, row 1

Column 4, row 1

Column 5, row 1

No

No

No

0

Passed tests

No

No

Yes

1

Failed tests

No

Yes

No

2

Skipped tests

No

Yes

Yes

3

Skipped/Failed tests

Yes

No

No

4

FailedWithinSuccess tests

Yes

No

Yes

5

FailedWithinSuccess/Failed tests

Yes

Yes

No

6

FailedWithinSuccess/Skipped tests

Yes

Yes

Yes

7

FailedWithinSuccess/Skipped/Failed tests