JUnit 5 test reporting

Learn how to report JUnit5 test results with Tesults. If you are not using JUnit5, view the Java docs for information about integrating with a lower level library.


The Tesults Java API Library and JUnit5 extension are available from the JCenter and Maven Central repositories.


If you are using Gradle add this dependency snippet to your build.gradle file:

dependencies {
  implementation 'com.tesults.junit5:tesults-junit5:1.2.0'

Also ensure you have the JCenter or Maven Central repository referenced in your build.gradle file.


If you are using Maven add this dependency snippet to your pom.xml file:



JUnit5 Extensions Enable

JUnit5 extensions auto-detection is disabled by default. To enable automatic extension detection set the junit.jupiter.extensions.autodetection.enabled configuration parameter to true. This can be supplied as a JVM system property.

Gradle example:

test {
  systemProperty 'junit.jupiter.extensions.autodetection.enabled','true'

Maven example: Use the Maven Surefire plugin.

            junit.jupiter.extensions.autodetection.enabled = true

Required to upload to Tesults, if this arg is not provided junit5-tesults does not attempt upload, effectively disabling it. Get your target token from the configuration menu in the Tesults web interface.

Inline method


In this case, the target token is supplied directly or inline in the args. This is the simplest approach.

Key method


In this case, junit5-tesults will automatically look up the value of the token based on the property provided from a configuration file. The path to the configuration file, specifically, a .properties file must be provided using the -DtesultsConfig=path-to-properties-file/tesults.properties, more details below.

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 = ...

Use this to provide a path to a configuration properties file


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. See more details above in the -DtesultsTarget arg description. The properties file can also contain all other args (without the -D prefix) to avoid having to pass them as in as system properties args. For example, the property file could contain TesultsFiles=/Users/admin/Desktop/TestFiles so you do not need to provide it as a system property. Then all you would need to pass as system properties are:

Basic configuration complete

At this point tesults-junit5 will have self registered and will push results to Tesults when you run your tests as long as this condition is met:

junit5-tesults requires the tesultsTarget system property to be supplied to indicate which target to use. See above for complete details.

Note: if you encounter issues where tests are not being discovered after adding the Tesults JUnit 5 dependency there may be a conflict related to junit-platform-launcher. Try adding this exclusion and try again. If you still encounter issues please contact help@tesults.com:


Do not add the exclusion above unless you are encountering the issue mentioned about test discoverability.

Files generated by tests

There are two ways to include files generated by tests.


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

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


import com.tesults.junit5.TesultsListener;
import org.junit.jupiter.api.TestInfo;

public class TestSuiteA {
  void Test1 (TestInfo testInfo) {
    TesultsListener.file(testInfo, "/full/path/to/file/log.txt");
    TesultsListener.file(testInfo, "/full/path/to/file/screenshot.png");
    assertEquals(1, 1);

Not Recommended

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


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.


This is one area where junit5-tesults 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.

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) {
  try {
    return f;
  } catch (IOException ex) {
    System.out.println("saveFile error: " + ex.getMessage());
    return null;

Please see the tags section for more details on how to provide a suite name and also take a look at the -DtesultsNoSuites flag below. The default behavior of junit5-tesults is to set the class name as the test suite if a test suite is not explicitly provided using a tag. 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

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



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



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



Use this to report a build description for reporting purposes.

-DtesultsBuildDesc=added new feature


Use this to report a build failure reason.

tesultsBuildReason=build error line 201 somefile.py
No Test Suites

Use this flag to stop automatic setting of the class name as the test suite in the case where a suite is not explicitly supplied using @Tag("suite=SuiteName")

If you are using Cucumber, the class name is not used as the name of the test suite and the JUnit 5 @Tag is not recognized. Do not set the tesultsNoSuite option when using Cucumber. Instead to set a test suite name add this to the top of your feature file: @suite=Test-Suite-A. Replace 'Test-Suite-A' with whatever you want for the name of the suite, without spaces.

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