TestNG test reporting

This a reference guide for setting up Tesults with your TestNG tests. If you are not using TestNG, view the Java docs for information about integrating with a lower level library.

Installation

The Tesults TestNG Listener extension makes setup easy. Add one dependecy to your project. The extension is available from the JCenter and Maven Central repositories.

Gradle

build.gradle
repositories {
  mavenCentral()
  jcenter()
}

dependencies {
  implementation 'com.tesults.testng:tesults-testng:1.1.0'
}

Maven

pom.xml
<dependency>
  <groupId>com.tesults.testng</groupId>
  <artifactId>tesults-testng</artifactId>
  <version>1.1.0</version>
</dependency>

Configuration

Once the dependency above has been specified your results data will be pushed to Tesults if you run your TestNG tests. By default the Tesults TestNG Listener will be disabled. To enable the listener you must provide the tesultsTarget argument with your target token to upload results. There are also other arguments that you can provide to report more detailed information, outlined below.

tesultsTargetRequired

The tesultsTarget and all other configuration values must be provided as JVM system properties. How you provide JVM system properties depends on whether you are invoking your tests from the command line, an IDE, or using Gradle or Maven. Here are examples:

Option 1: Command line

java -DtesultsTarget=token -cp "jar-path/testng.jar:test-classes-path" org.testng.TestNG testng.xml

Option 2: Gradle

build.gradle
test {
  useTestNG()
  systemProperty "tesultsTarget", 'token'
}

Option 3: Maven

Use the Maven Surefire plugin.

pom.xml
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.22.0</version>
      <configuration>
        <systemPropertyVariables>
          <tesultsTarget>token</tesultsTarget>
        </systemPropertyVariables>
      </configuration>
    </plugin>
  </plugins>
</build>

Option 4: IDE

You can also provide JVM system properties through IDE functionality. Eclipse and IntelliJ provide built in ways to specificy these properties.


-tesultsConfigOptional

Use this to provide a path to a configuration properties file

-DtesultsConfig=/full-path/tesults.properties

The properties file is useful to store several Tesults target tokens that can then be automatically be looked up by supplying an easy to remember target name. This allows you to supply only the tesultsTarget (with a label rather than the token itself) and tesultsConfig as JVM system properties. The properties file can contain all other args to avoid having to pass them as in as system properties args.

-DtesultsTarget=target1 -DtesultsConfig=/full-path/tesults.properties

In this case, the Tesults TestNG Listener will automatically look up the value of the token based on the property provided from a configuration file.

Here is the corresponding tesults.properties file:

target1 = eyJ0eXAiOiJ...
target2 = ...
target3 = ...
target4 = ...

Or something more descriptive about the targets:

web-qa-env = eyJ0eXAiOiJ...
web-staging-env = ...
web-prod-env = ...

ios-qa-env = eyJ0eXAiOiK...
ios-staging-env = ...
ios-prod-env = ...

android-qa-env = eyJ0eXAiOiL...
android-staging-env = ...
android-prod-env = ...

Basic configuration complete

At this point Tesults TestNG Listener will push results data to Tesults when your tests run as long as the tesultsTarget system property is supplied to indicate which target to use.

Reporting custom fields and values

Ensure you have version 1.1.0 + of the tesults-testng library installed and use the built in custom method to report custom properties.

To do this, inject the Method parameter into your test and then call the custom method on TesultsListener passing in Method and the name of the custom field and the value.

Example:

import com.tesults.testng.TesultsListener;
import org.testng.annotations.*;
import java.lang.reflect.Method;
public class TestSuiteA {
  @Test
  public void Test1 (Method method) {
    TesultsListener.custom(method, "Custom field name", "Custom field value");
  }
}

If you already injecting another parameter, add Method as another parameter at the end:

@Test
public void Test1 (ITestContext context, Method method) {
}

Files generated by tests

There are two ways to include files generated by tests.

Recommended

The recommended approach is to ensure you have version 1.1.0 + of the tesults-testng library installed and then use the built in file method.

To do this, inject the Method parameter into your test and then call the file method on TesultsListener passing in Method and the full path to the file.

Example:

import com.tesults.testng.TesultsListener;
import org.testng.annotations.*;
import java.lang.reflect.Method;
public class TestSuiteA {
  @Test
  public void Test1 (Method method) {
    TesultsListener.file(method, "/full/path/to/file/log.txt");
    TesultsListener.file(method, "/full/path/to/file/screenshot.png");
  }
}

If you already injecting another parameter, add Method as another parameter at the end:

@Test
public void Test1 (ITestContext context, Method method) {
}

Not Recommended

This second method is no longer recommended but can be used if desired.

tesultsFilesOptional

Provide the top-level directory where files generated during testing are saved for the running test run. Files, including logs, screen captures and other artifacts will be automatically uploaded.

-DtesultsFiles=/Users/admin/Desktop/temporary

This is one area where the Tesults TestNG Listener is opinionated and requires that files generated during a test run be saved locally temporarily within a specific directory structure.

Store all files in a temporary directory as your tests run. After Tesults upload is complete, delete the temporary directory or just have it overwritten on the next test run.

The default behavior of the Tesults TestNG Listener is to set the class name as the test suite. Also be aware that if providing build files, the build suite is always set to [build] and files are expected to be located in temporary/[build]/buildname

You can utilize a function such as this one to create a file at a path that meets this requirement:

public File createFile (String suite, String test, String file) {
  String temp = "/Users/admin/Desktop/temp"; // tesultsFiles arg value
  String path = temp + File.separator + suite;
  path = path + File.separator + test;
  path = path + File.separator + file;
  File f = new File(path);
  File dir = f.getParentFile();
  if (dir != null) {
    dir.mkdirs();
  }
  try {
    f.createNewFile();
    return f;
  } catch (IOException ex) {
    System.out.println("saveFile error: " + ex.getMessage());
    return null;
  }
}

Caution: If uploading files the time taken to upload is entirely dependent on your network speed. Typical office upload speeds of 100 - 1000 Mbps should allow upload of even hundreds of files quite quickly, just a few seconds, but if you have slower access it may take hours. We recommend uploading a reasonable number of files for each test case. The upload method blocks at the end of a test run while uploading test results and files. When starting out test without files first to ensure everything is setup correctly.

During a test run, save test generated files such as logs and screenshots to a local temporary directory. At the end of the test run all files will automatically be saved to Tesults as long as you save files in the directory structure below. Omit test suite folders if not using test suites.
  • expanded temporary folder
    • expanded Test Suite A
      • expanded Test 1
        • test.log
        • screenshot.png
      • expanded Test 2
        • test.log
        • screenshot.png
    • expanded Test Suite B
      • expanded Test 3
        • metrics.csv
        • error.log
      • expanded Test 4
        • test.log

Build

tesultsBuildName=buildnameOptional

Use this to report a build version or name for reporting purposes.

-DtesultsBuildName=1.0.0

tesultsBuildResult=resultOptional

Use this to report the build result, must be one of [pass, fail, unknown].

-DtesultsBuildResult=pass

tesultsBuildDesc=descriptionOptional

Use this to report a build description for reporting purposes.

-DtesultsBuildDesc=added new feature

tesultsBuildReason=reasonOptional

Use this to report a build failure reason.

-DtesultsBuildReason=build error line 201 somefile.py

No Test Suites


tesultsNoSuitesOptional

Use this flag to stop automatic setting of the class name as the test suite.

-DtesultsNoSuites

How TestNG test cases are reported in Tesults

This example TestNG test file includes one class with three test functions. Tesults would report the suite as TestSuiteA, the test cases would be reported as the names of the functions, test1, test2 and test3. The last test is parameterized and Tesults would report two separate test cases for this, it would pick up the test file for test1 along with the descriptions for test 1 and 3. All tests would be reported as passes except for test2 which would be a fail and the reason for the failure would include the assert message.

TestNG Tests Example: TestSuiteA.java
import java.io.File;
import java.io.IOException;
import org.testng.Assert;
import org.testng.annotations.*;

public class TestSuiteA {
  @Test (description = "test1 description")
  public void test1() {
    createFile("TestSuiteA", "test1", "hey.log");
  }

  @Test
  public void test2() {
    Assert.fail("This message will appear as the test failure reason.");
  }

  @DataProvider(name = "values")
  public Object[][] createData() {
    return new Object[][] {
      { "Summer", "Hot" },
      { "Winter", "Cold"},
    };
  }

  @Test (dataProvider = "values", description = "test3 description")
  public void test3(String season, String feels) {
    System.out.println("the season is " + season);
    System.out.print("feels: " + feels);
  }
}

Result Interpretation

Result interpretation is not currently supported by this integration. If you are interested in support please contact help@tesults.com.

Consolidating parallel test runs

If you execute multiple test runs in parallel or serially for the same build or release and results are submitted to Tesults within each run, separately, you will find that multiple test runs are generated on Tesults. This is because the default behavior on Tesults is to treat each results submission as a separate test run. This behavior can be changed from the configuration menu. Click 'Results Consolidation By Build' from the Configure Project menu to enable and disable consolidation by target. Enabling consolidation will mean that multiple test runs submitted with the same build name will be consolidated into a single test run.

Dynamically created test cases

If you dynamically create test cases, such as test cases with variable values, we recommend that the test suite and test case names themselves be static. Provide the variable data information in the test case description or other custom fields but try to keep the test suite and test name static. If you change your test suite or test name on every test run you will not benefit from a range of features Tesults has to offer including test case failure assignment and historical results analysis. You need not make your tests any less dynamic, variable values can still be reported within test case details.

Proxy servers

Does your corporate/office network run behind a proxy server? Contact us and we will supply you with a custom API Library for this case. Without this results will fail to upload to Tesults.

Have questions or need help? Contact us