Run tests using a CI system

The procedure below focuses on Jenkins, but you can apply the same concepts to most CI systems.

Note: If you are running OpenText Functional Testing for Developers tests from Jenkins, you can track the tests in OpenText Application Quality Management. For details, see the ALM Help Center.

  1. Install the OpenText Functional Testing for Developers runtime engine and your AUT on the agent.

    If your tests were created in the context of a unit testing framework (such as NUnit or JUnit), make sure that the relevant framework's runner is also installed on the agent computer.

  2. Deploy the tests (DLLs/JARs) to the agent computer.

  3. Configure the Jenkins agent to maintain an active Windows session. This is needed so that the runtime engine can access the UI elements of your AUT during the run.

  4. For non-Web applications:

    1. On the agent computer, start the UFT Helper service from: Computer > Manage > Services and Applications > Services.

      Note: Make sure the service starts before the runtime engine.

    2. In the Engine tab of the Settings dialog box, under Runtime Settings, enter the user name and encrypted password of the agent computer.

      To generate the encrypted password, run the following command line from the agent computer and copy the encrypted string to the clipboard:

      On Windows: <Installdir>\bin\PasswordEncryption.exe -me <password-to-encode>

      On Linux/Mac: Run <Installdir>/Tools/password-encoder <password-to-encode> [-me]

      Note: The encrypted password is based on the computer on which you run the utility, so make sure to generate the password on the computer on which you plan to use it.

  5. Configure your Jenkins job to run your tests.

    For example if your tests were created in the context of an NUnit project, your build step may look like this: 

    <NUnit Path>\bin\nunit-console-x86.exe "%PATH_TO_TEST_PROJECT_DLL%\DLLFileName.dll"

  6. (Optional) Configure your job to archive the HTML report files, so that they are available in Jenkins for each build of your job. You can also customize your job to include a direct link to the test run report file for each build.

  7. (Optional) If your CI system expects test results in JUnit format, you can convert the run result report to the JUnit format before publishing results to the CI system.

    You can configure the test project to generate a JUnit report at the end of each run. Alternatively, you can run the JUnitReportBuilder CLI tool to convert existing XML or JSON reports into a JUnit one.

Converting existing run result reports to JUnit reports

The JUnitReportBuilder tool converts one or more run result reports into a single JUnit report.

This is useful when you need to integrate run results with CI/CD systems or tools that expect JUnit-formatted reports, and the tests you ran were not configured to provide JUnit reports.

The junitReportBuilder.exe is located in <Installdir>\Tools\Report.

  • The tool can receive a path to a folder containing XML run result reports or paths to one or more report files.

  • Each time you run the tool, it converts the reports you specified in the parameters into a single JUnit report.

The report files must be XML reports, or, for JavaScript test projects, JSON reports.

Parameter Details
The path to a folder containing run result XML files. All files whose name matches runresults*.xml in the specified folder and its subfolders are converted.
The paths to one or more run XML or JSON result files.

If you specify paths to multiple files, separate the paths with spaces.

The file names must follow the pattern: runresults*.xml

For JavaScript test projects JSON reports, the file names must follow the pattern: runresults*.json

For example: junitReportBuilder.exe runresults.xml runresults1.xml runresults_2.xml

See also