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):
--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
- 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.0for 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:
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! 😎