Distributed Execution for Test Automation

When it comes to Selenium web testing, sooner or later a need for scalability arises and instead of executing tests on a single browser, we want to cover all the possible options and supported browsers. The same goes for Appium mobile testing as we look for methods to tests on more than just one device, but rather on a variety of available devices and emulators/simulators.

Selenium Grid is a widely known & used tool that allows test case execution across different platforms, operating systems and browsers with various combinations. Using OpenSDK, you can create a grid similar to Selenium or Appium Grid, but with all the added benefits and features of TestProject’s free test automation platform, such as built-in dashboards, local test reports, automated CI flows, seamless collaboration capabilities and zero setup or maintenance hassles – just to name a few 😉

TestProject’s Agent is a powerful wrapper for Selenium and Appium and with a single “next-next” simple installation, you instantly gain access to all browsers and connected devices on the machine you install it on. Having multiple Agents allows you to scale your test automation by distributing the execution of your tests and creating a lab of multiple execution targets (any browser or Android/iOS device).

Distributed Execution using Agent and CLI

By default, the TestProject Agent starts its web server, binding it to localhost only. Starting from Agent version 2.2.0 and OpenSDK version 1.1.0 or greater, in order to enable external connectivity for OpenSDK, additional parameters can be used along with the TestProject Agent CLI (command-line interface):

Using --rest-address, the Agent can be instructed for binding its Web Server to other available interfaces and a concrete port. The following command starts the Agent, binding its web server to all the available interfaces of the machine it’s running on and to port 65200 (for example):

testproject-agent start --rest-address 0.0.0.0:65200

💡 Notes:

• You can use any available port number, and not necessarily the one used in the example above.
• You can bind to a specific host/IP, or use 0.0.0.0 for binding to all available interfaces.

Using OpenSDK, for example the Java OpenSDK, you can override the default Agent address, and instead of connecting to a local Agent, you can connect to a remote Agent in order to work with it and use the Browsers or the Devices connected to it:

driver = new ChromeDriver(new URL("http://10.0.0.2:65200"), new ChromeOptions());

For additional info regarding using remote Agents, refer to each OpenSDK documentation on GitHub:

• JavaScript
• Java
• Python
• C#

By completing the above, you can create a lab of Agents with different capabilities to scale and distribute tests across multiple targets.

Distributed Execution using Agent in Docker

Another option allowing binding the Agent to additional interfaces is by passing environment variables. This can be extremely useful with Agents running in Docker 🐳

docker run -e TP_AGENT_REST_ADDRESS=0.0.0.0:65200 --name agent testproject/agent:2.2.0

The line above will bind the Agent to any available interface using the provided wild card IP 0.0.0.0 and for example port 65200 (of course you can use any other available port). After configured, an appropriate line will appear in the Docker logs:

Binding REST API to: 0.0.0.0:65200

Thus, the OpenSDK can communicate with the Agent remotely.

The same can be achieved when using docker-compose by simply adding the following line:

TP_AGENT_REST_ADDRESS: 0.0.0.0:65200 # Address for accessing the Agent in local network 

Here is the complete docker-compose script example:

# NOTE: Make sure to update the 'testproject-agent' container volume with a valid local path.
# To execute this docker-compose, store it in a file (e.g. testproject-agent.yaml) an run:
# docker-compose -f <file_name> up -d

version: "3.1"
services:
  testproject-agent:
    image: testproject/agent:latest
    container_name: testproject-agent
    depends_on:
      - chrome
      - firefox
    environment:
      TP_API_KEY: "<YOUR API KEY>"
      TP_SDK_PORT: "8686"             # Agent will listen on port 8686 for SDK connections
      CHROME: "chrome:4444"           # Address for Agent to communicate with Chrome browser
      CHROME_EXT: "localhost:5555"    # Address for accessing the Chrome Selenium server
      FIREFOX: "firefox:4444"         # Address for Agent to communicate with Firefox browser
      FIREFOX_EXT: "localhost:5556"   # Address for accessing the Firefox Selenium server
      TP_AGENT_REST_ADDRESS: 0.0.0.0:65200 # <--- Address for accessing the Agent in local network

    ports:
    - "8585:8585"
    - "8686:8686"                     # Expose port for SDK<->Agent communication
  chrome:
    image: selenium/standalone-chrome
    volumes:
      - /dev/shm:/dev/shm
    ports:
    - "5555:4444"                     # Expose Selenium on port 5555
  firefox:
    image: selenium/standalone-firefox
    volumes:
      - /dev/shm:/dev/shm
    ports:
    - "5556:4444"                     # Expose Selenium on port 5556

There are multiple ways to expose the TestProject Agent for remote execution by the OpenSDK. Once an Agent starts “listening” on other interfaces besides the localhost, it paves the way towards distributed execution of tests, creating a net of multiple Agents with different capabilities across various desired targets.

Happy Testing! 😎