Run tests in Docker containers

This topic explains how to use OpenText Functional Testing for Developers Docker images to run your tests in Docker containers.

In this topic:

Integrating with Docker

Docker is a software container platform. It is designed to make it easier to create, deploy, and run applications by using containers. Containers include everything required to make software run. They do not bundle a full operating system (like VMs do), only libraries and settings, which make them efficient, lightweight, self-contained systems.

OpenText Functional Testing for Developers provides Docker images enabling you to run your tests in Docker containers.

Docker is supported for all Web and mobile technologies.

Using Docker containers has major benefits for developers, DevOps, and the enterprise:

• Zero installation. Run tests without having OpenText Functional Testing for Developers installed on your machine.
• Background execution. Run your tests in the background and continue to work without distraction.

• Execution box. Use a single command to run the Docker image, run the test, and close the container when the test is done.

• CI/CD readiness. Streamline software delivery by supporting continuous integration and continuous delivery. For details, see Run tests using a CI system.

Back to top

OpenText Functional Testing for Developers Docker images

The following docker images are available:

• functionaltesting/uftdeveloper. The basic OpenText Functional Testing for Developers image, which contains the engine and the capabilities to run tests.
• functionaltesting/uftdeveloper-chrome. The basic OpenText Functional Testing for Developers image with a Chrome browser.
• functionaltesting/uftdeveloper-firefox. The basic OpenText Functional Testing for Developers image with a Firefox browser.
• functionaltesting/uftdeveloper-edge. The basic OpenText Functional Testing for Developers image with an Edge browser.

You can use the basic functionaltesting/uftdeveloper image and create a customized image that runs a different browser version. For instructions refer to the Docker Hub documentation.

The latest version of all OpenText Functional Testing for Developers docker images come with Java 11 and .NET 8.0 installed.

Back to top

Standalone mode vs. execution box mode

You can run OpenText Functional Testing for Developers tests in two modes: standalone or as an execution box.

Standalone

This mode is like running tests remotely.

In this mode, you start the OpenText Functional Testing for Developers container which launches the runtime engine. The engine then waits for commands. You run the test separately, on your machine. You may need to update the runtime engine address (IP or host name) in the test in order to connect to the Docker image. When you run the test, the commands are run within the Docker container. You need to stop the container when you are done.

For details on running tests remotely, see Run tests remotely.

Execution box

This mode is like running the runtime engine and the test on the same machine.

In this mode, you run the OpenText Functional Testing for Developers container, which launches the test within the container and closes the container when the test completes.

Back to top

License usage

OpenText Functional Testing for Developers Docker integration is supported only for concurrent licenses. For more details on license types, see Licensing.

When you run the OpenText Functional Testing for Developers image, you need to indicate which license server to use. You can do that in one of two ways:

• Using --add-host=license-server:<enter your license address>
• Using the LFT_LIC_SERVER environment variable. For more details, see License.

Back to top

Download the Docker image

Before you begin you must first have Docker installed on your machine.

Download one of the following images to your machine using the pull command from a command line:

• functionaltesting/uftdeveloper-edge

• functionaltesting/uftdeveloper
• functionaltesting/uftdeveloper-chrome
• functionaltesting/uftdeveloper-firefox

For example:

Back to top

Run the Docker image

This sections explains how to run your Docker image:

1. Decide in which mode you want to run the Docker image standalone mode or execution box. For details, see Standalone mode vs. execution box mode.

2. To run the Docker image in standalone mode:

   Run the following from a command line:

   docker run -it -p 5095:5095 -p 5900:5900 --add-host=license-server:xx.xx.xx.xx <OpenText Functional Testing for Developers container>

   What does this command do?

   Command	Description
   docker run	The Docker CLI command for running the container.
   -it	Instructs the Docker to run in the foreground so that you can track the output of the container. You can use Ctrl+C to stop the container.
   -p 5095:5095	Maps the host's 5095 port (the OpenText Functional Testing for Developers default port) to the container's 5095 port, to connect to the runtime engine.
   -p 5900:5900	Optional. Maps port 5900 to the container's 5900 port, to connect to a VNC. Use this option if you would like to see the Docker container. For example, for debugging purposes. When you connect to the VNC client, use the password: PASSWORD
   --add-host=license-server:xx.xx.xx.xx	Instructs the container which IP address to use for the license server. Replace xx.xx.xx.xx with your license server IP address.
   <OpenText Functional Testing for Developers container>	Instructs Docker to create a container. Possible values: functionaltesting/uftdeveloper, functionaltesting/uftdeveloper-chrome, functionaltesting/uftdeveloper-edge, functionaltesting/uftdeveloper-firefox. Optionally, append :<version number> to the container name. By default the latest version is used.

   Note:  

   • The report is generated from the location as the test is run.
   • You can also use docker's -u <name|uid>[:<group|gid>] option to specify the user to use in the container.
   • If you need to provide a self-signed certificate for the Chrome or Firefox browser to use inside the docker container, see Enable tests to access a web site using a self-signed certificate.

   Use environment variables as required. For details, see Run the docker image with environment variables.

3. To run the Docker image as an execution box, run one of the following from a command line:

   .NET C#

   For NUnit or MSTest tests:

   To run from a compiled project: 

   docker run -it -p 5900:5900 --add-host=license-server:xx.xx.xx.xx -e RUN_MODE=custom -e RUN_CMD="dotnet test UFTdNUnitTest.dll --settings test.runsettings --filter tests.UftDeveloperTest2.TestGetSnapshot" -v <full path on the host’s machine to the project .dll>:/tests -w /tests <OpenText Functional Testing for Developers container>

   To run from the .NET project source code: 

   docker run -it -p 5900:5900 --add-host=license-server:xx.xx.xx.xx -e RUN_MODE=custom -e RUN_CMD="dotnet test --settings test.runsettings --filter tests.UftDeveloperTest2.TestGetSnapshot" -v <full path on the host’s machine to the .NET project source code>:/tests -w /tests <OpenText Functional Testing for Developers container>

   Note:

   • This command performs operations in the working folder and must have read/write/execute permissions.

     You can achieve this by prefacing the command with sudo, to run it with administrator privileges or by making sure the folder containing the tests has full permissions.

     Grant these permissions to the user you specify in the run command, or to all users, if you use the default “leanft-user” account, which is created when running the tests.

   • The --settings and --filter arguments are optional, providing an XML settings file, which contains runtime parameters for the test, and a filter option specifying which of the project's tests to run.

   Java

   For JUnit tests: 

   docker run -it -p 5900:5900 --add-host=license-server:xx.xx.xx.xx -e RUN_MODE=junit -e RUN_CMD="com.company.UFTDeveloperTest" -v <full path on the host’s machine to java jars>:/tests -w /tests <OpenText Functional Testing for Developers container>

   For TestNG tests: 

   docker run -it -p 5900:5900 --add-host=license-server:xx.xx.xx.xx -e RUN_MODE=testng -e RUN_CMD="testngMyApp.xml" -v <full path on the host’s machine to java jars>:/tests -w /tests <OpenText Functional Testing for Developers container>

   JavaScript

   docker run -it -p 5900:5900 --add-host=license-server:xx.xx.xx.xx -v <full path on the host’s machine to javascript mocha project>:/tests -w /tests <OpenText Functional Testing for Developers container>

   Note: This command runs npm test, which runs the test script in the package.json file. Make sure that the test script is defined correctly in the file. For example:

   "scripts": {
   "test": "jasmine plutoE2e.js"
   }

   What do these commands do?

   Command	Description
   docker run	The Docker CLI command for running the container.
   -it	Instructs the Docker to run in the foreground so that you can track the output of the container. You can use Ctrl+C to stop the container.
   -p 5900:5900	Optional. Maps port 5900 to the container's 5900 port, to connect to a VNC. Use this option if you would like to see the Docker container. For example, for debugging purposes. When you connect to the VNC client, use the password: PASSWORD
   --add-host=license-server:xx.xx.xx.xx	Instructs the container which IP address to use for the license server. Replace xx.xx.xx.xx with your license server IP address.
   -e RUN_MODE=junit or -e RUN_MODE=testng or -e RUN_MODE=custom	Use for Java and .NET tests: Indicates the framework used to run the test. Possible values:  junit - indicates that this is a JUnit test. testng - indicates TestNG tests. custom - use this for .NET C# tests. For each type, make sure to provide the relevant value in RUN_CMD.
   -e RUN_CMD="com.company.UFTDeveloperTest" or -e RUN_CMD="testngMyApp.xml" or -e RUN_CMD="testngMyApp.xml"	Specifies the run command according to the type of test: For JUnit, Specifies the class that the container should use to run the test. For TestNG, specifies the TestNG configuration XML file that the container should use to run the test. Make sure the XML file is located under the host directory that is mapped to the container. Note: If the XML file is not located in the same folder as the test jar file, specify the file's full path, or a path relative to the test jar file. For .NET, specifies the dotnet test command line.
   -v <full path on the host’s machine to the test files>:/tests	Maps the host’s test directory to the container's /tests directory. After the test report is generated you can access it from your machine in the path you defined.
   -w /tests	Indicates that the working directory on the container is /tests. The tests are run from this location and this is where the tests reports are generated.
   <OpenText Functional Testing for Developers container>	Instructs Docker to create a container. Possible values: functionaltesting/uftdeveloper, functionaltesting/uftdeveloper-chrome, functionaltesting/uftdeveloper-edge, functionaltesting/uftdeveloper-firefox. Optionally, append :<version number> to the container name. By default the latest version is used.

   Note: If you need to provide a self-signed certificate for the Chrome or Firefox browser to use inside the docker container, see Enable tests to access a web site using a self-signed certificate.

   Use environment variables as required. For details, see Run the docker image with environment variables.

4. After your container is up and running, run your tests from your local machine as you always do. The browser is launched inside the container and your script commands are run there.

Back to top

Run the docker image in a grid configuration

You can set up an OpenText Functional Testing for Developers grid configuration using multiple docker containers. Run one container as a grid and others as grid nodes. For details on using a grid, see Use a grid configuration.

Use environment variables as required. For details, see Run the docker image with environment variables.

To run tests in a grid configuration using docker images

1. Run an OpenText Functional Testing for Developers docker image as a grid

   docker run -it -p 5095:5095 -p 8080:8080 --add-host=license-server:xx.xx.xx.xxx -e LFT_RUN_MODE="grid" -e LFT_GRID_PASSPHRASE="<encrypted passphrase>" <OpenText Functional Testing for Developers container>

   What does this command do?

   Command	Description
   docker run	The Docker CLI command for running the container.
   -it	Instructs the Docker to run in the foreground so that you can track the output of the container. You can use Ctrl+C to stop the container.
   -p 5095:5095	Maps the host's 5095 port (the OpenText Functional Testing for Developers default engine port) to the grid container's 5095 port, to connect to the OpenText Functional Testing for Developers engine.
   -p 8080:8080	Maps the host's 8080 port (the OpenText Functional Testing for Developers default management port) to the grid container's 8080 port, to use for the grid management user interface.
   --add-host=license-server:xx.xx.xx.xx	Instructs the container which IP address to use for the OpenText Functional Testing for Developers license server. Replace xx.xx.xx.xx with your license server IP address.
   "-e LFT_RUN_MODE="grid"	Instructs the container to run OpenText Functional Testing for Developers as a grid.
   -e LFT_GRID_PASSPHRASE="<encrypted passphrase>"	Specifies the passphrase that nodes need to use to connect to the grid.
   <OpenText Functional Testing for Developers container>	Instructs Docker to create a container. Possible values: functionaltesting/uftdeveloper, functionaltesting/uftdeveloper-chrome, functionaltesting/uftdeveloper-edge, functionaltesting/uftdeveloper-firefox. Optionally, append :<version number> to the container name. By default the latest version is used.

2. Run OpenText Functional Testing for Developers docker images as grid nodes

   docker run -it -p 5900:5900 -e LFT_RUN_MODE="node" -e LFT_GRID_PASSPHRASE="<encrypted passphrase>" -e LFT_GRID_NODE_NAME="<Node Name>" -e LFT_GRID_ADDRESS="ws://<IP address>:5095" <OpenText Functional Testing for Developers container>

   What does this command do?

   Command	Description
   docker run	The Docker CLI command for running the container.
   -it	Instructs the Docker to run in the foreground so that you can track the output of the container. You can use Ctrl+C to stop the container.
   -p 5900:5900	Optional. Maps the host's port 5900 to the node container's 5900 port, to connect to a VNC. Use this option if you would like to see the Docker container. For example, for debugging purposes. When you connect to the VNC client, use the password: PASSWORD Note: When running additional node containers on the same host, you must map each node container's 5900 port to a different host port. For example, use -p 5900:5900 for the first node, -p 5901:5900 for the second, -p 5902:5900 for the third, and so on.
   --add-host=license-server:xx.xx.xx.xx	Instructs the container which IP address to use for the OpenText Functional Testing for Developers license server. Replace xx.xx.xx.xx with your license server IP address.
   "-e LFT_RUN_MODE="node"	Instructs the container to run OpenText Functional Testing for Developers as a grid node.
   -e LFT_GRID_PASSPHRASE="<encrypted passphrase>"	Instructs the container what passphrase to use to connect to the grid.
   -e LFT_GRID_NODE_NAME="<Node Name>"	Specifies the name the grid uses to identify this node.
   -e LFT_GRID_ADDRESS="ws://<IP address>:5095 Alternatively, map the grid host address: --add-host=grid:<grid's IP address>	Instructs the node container what address to use to access the grid container. You can do this by setting the LFT_GRID_ADDRESS environment variable or by mapping grid to the grid container's IP address. Note: When the environment variable is not set, a node machine looks for the grid at ws://grid:5095. If you want to use a different port number, you must set the environment variable.
   <OpenText Functional Testing for Developers container>	Instructs Docker to create a container. Possible values: functionaltesting/uftdeveloper, functionaltesting/uftdeveloper-chrome, functionaltesting/uftdeveloper-edge, functionaltesting/uftdeveloper-firefox. Optionally, append :<version number> to the container name. By default the latest version is used.

   Note:  

   • If you use the uftdeveloper-<browsername> images, OpenText Functional Testing for Developers knows which browser the image contains and you do not need to define the browser capability on the node.

   • You can also use docker's -u <name|uid>[:<group|gid>] option to specify the user to use in the container.

   • If you need to provide a self-signed certificate for the Chrome or Firefox browser to use inside the docker container, see Enable tests to access a web site using a self-signed certificate.

3. After your containers are up and running, run your OpenText Functional Testing for Developers tests locally or remotely on the grid container. The grid distributes the tests to the relevant nodes, based on availability and the environment specifications you included in the tests.

Back to top

Run the docker image with environment variables

Run the OpenText Functional Testing for Developers docker image with various environment variables to control how the container runs.

Prefix each variable that you run with -e. For example: 

The following tables includes the environment variables, their description, and possible values:

• Run commands

• Grid configuration

• License

• Proxy

• Enable tests to access a web site using a self-signed certificate

Run commands

The following table describes variables that control the run command.

Variable	Description	Possible values
RUN_MODE	Determines how to run the container.	junit: runs a JUnit test using the class specified in RUN_CMD. testng: runs a TestNG test using the TestNG XML file specified in RUN_CMD. s/sa/standalone: runs the container in standalone mode. c/custom: runs the command specified in RUN_CMD.
RUN_CMD	Runs a command.	The command to run. For RUN_MODE=junit, specify the class to run. For RUN_MODE=testng, specify the TestNG configuration XML file. For RUN_MODE=c/custom, specify the custom command you want to run.
VERBOSE	Determines whether to print debug information.	true
LFT_SAPUI5_ADDIN	Indicates loading the SAPUI addin.	true
NOVNC	Indicates turning off the VNC session. The default is false.	true
USER_UID	If you run docker on Linux , we recommend that you pass your user ID in order to manage the test results files.	Your user ID
USER_GID	(Optional) If you run docker on Linux , pass your group ID to provide group permissions.	Your group ID

Grid configuration

The following table describes variables to use for in a grid configuration.

Variable	Description	Possible values
LFT_RUN_MODE	Runs the container as a grid or a node.	grid, node. If you do not set this environment variable, the container runs an independent OpenText Functional Testing for Developers and not a grid.
LFT_GRID_PASSPHRASE	The encrypted case-sensitive passphrase that nodes must use when connecting to the grid.	Provide the same passphrase for the grid and the nodes that need to connect to it. Encrypt the passphrase using the docker container machine encryption. For example: docker run -it uftdeveloper /opt/leanft/Tools/password-encoder -me <passphrase>

Grid machine See also Configure the grid's runtime engine settings.

The following table describes variables to use on a grid machine.

Variable	Description	Possible values
LFT_GRID_MAX_LIC	The maximum number of concurrent licenses the grid is allowed to consume.	Maximum number of licenses
LFT_GRID_LIC_TIMEOUT	The license timeout for the grid.	License timeout
LFT_GRID_WAIT_TIMEOUT	The maximum number of seconds to wait for one of the locks on a relevant node to be released, if all nodes are currently in use and reached their lock maximum.	Node-wait timeout

Grid node machines. See also Grid Connection Settings.

The following table describes variables to use on grid node machines.

Variable	Description	Possible values
LFT_GRID_NODE_NAME	A unique name for the grid to use for this node.	A unique name
LFT_GRID_ADDRESS	The data needed for the node to connect to the grid machine.	Use the following format: wss|ws://server-address:port number. By default, ws://grid:5095. If you do not set this environment variable, make sure you map the grid host to the grid's IP address when running the node container.
LFT_GRID_NODE_MAX_LOCKS	The maximum number of simultaneous times the grid can choose this node for running a test.	Maximum number of locks

License

The following table describes variables to use for the concurrent license installation.

Variable	Description	Possible values
LFT_LIC_SERVER	The license server IP address or host name. Can be used instead of --add-host=license-server:xx.xx.xx.xx	The license server IP address or host name.
LFT_LIC_ID	The license ID that you want to use. The default is 20524.	license number
LFT_LIC_ID_VERSION	The license ID version. The default is 1.	version number

OpenText Functional Testing Lab

The following table describes variables to use to connect to OpenText Functional Testing Lab.

Variable	Description	Possible values
LFT_HPEMC_ADDRESS	Use this variable along with LFT_HPEMC_USER and LFT_HPEMC_PASS to run OpenText Functional Testing Lab in the container.	The OpenText Functional Testing Lab IP address or host name.
LFT_HPEMC_USER	The OpenText Functional Testing Lab user name used for logging on.	The OpenText Functional Testing Lab user name.
LFT_HPEMC_PASS	The OpenText Functional Testing Lab password used for logging on.	An encrypted password using the docker container machine encryption. For example: docker run -it uftdeveloper /opt/leanft/Tools/password-encoder -me <password>
LFT_HPEMC_USE_PROXY	Indicates whether OpenText Functional Testing Lab runs behind a proxy.	True or False
LFT_PROXY_ADDRESS	The proxy IP address or host name.
LFTRUNTIME_labs__mobileCenter__serverInfo__ignoreCertificatesErrors	Indicates whether or not to validate the certificate. By default, Full SSL (Strict) is employed. However, you can set this variable to True to ignore certificate errors.	True or False

Proxy

Use these variables if you are running behind a proxy server.

Variable	Description	Possible values
http_proxy	Your organization's http proxy.	Host name or IP address and port
https_proxy	Your organization's https proxy.	Host name or IP address and port
no_proxy	Any address that does not require a proxy, such as you local host.	Host name or IP address and port

Enable tests to access a web site using a self-signed certificate

Supported for Chrome and Firefox browsers only

Your tests may need to access a web application that requires a self-signed certificate. You can enable this by providing the certificate when running the docker container.

To provide a self-signed certificate for the Chrome or Firefox browser to use inside the docker container:

1. Place the certificate on the host machine, under the folder that you map to the docker container.

2. Add the following environment variables to the docker run commands:

   Environment variable	Description
   CERTIFICATE_FILE_PATH	The internal mapped path of the certificate file in the docker container. For example:  -e CERTIFICATE_FILE_PATH=/tests/certificate_file.crt
   CERTIFICATE_TRUST_ARGS   (Used for Chrome only)	Parameters for managing the certificate, using the NSS Tools certutil. For details, see online documentation about this tool. Default : "TCu,Cuw,Tuw" For example:  -e CERTIFICATE_TRUST_ARGS="TCu,Cuw,Tuw"

For example:

Back to top

See also:

• Execute your LeanFT tests in Docker
• OpenText Functional Testing for Developers Security Reference: OpenText Functional Testing for Developers Docker container security