Why do I need TestProject Agents inside Docker containers?

Containers are a perfect companion to the agile movement. Organizations today need fast paced & efficient software teams & with that comes the hefty practice of continuous pushing of source code from development to testing & production multiple times. With Docker’s ability to isolate environments with specific dependencies & the flexibility to ship them from or to different environments makes the work more efficient & reliable.

Docker containers can accelerate your test automation platform using “dockerized” TestProject Agents. What makes the docker agent useful is that it saves a bunch of resources & provides the ability to run tests with just a simple command. For most cases you’ll need to set up the TP_API_KEY from the web console which is a way of authorizing the docker agent to an account. Optionally, you’ll need a Job id TP_JOB_ID if you want the containers to execute directly instead of waiting for instructions from the web UI.

You can set up the agent in two ways:

  • Giving signals to execute jobs right from the web UI.
  • Or providing dedicated tokens beforehand for seamless execution of jobs without the need for manual intervention.

Setting up TestProject Agents in Docker

Requirements

  • All you need is a TestProject account, that’s it! If you don’t already have one, you can sign up and open your free account here.

The TestProject Agent docker container can be used in two distinct ways, as also described in our DockerHub page:

  • Permanent Execution Engine – The agent is registered once, and then can be used to execute tests and jobs from the TestProject web application
  • Ephemeral Instances – In this scenario the agent is started up in order to perform a specific task, and will self terminate upon completion of said task.

The operation mode of the agent is controlled by environment variables that are passed to the container upon creation.

Permanent Execution Engine

Let’s say you want to run multiple jobs & don’t want a fresh container for each test run. Your test capitalizes on a cache previously saved from a test run to continue further execution. Running tests from the start is a bit of an overkill even when using containers.

This is where instances that have saved states come in to the picture.

The flexibility to resume or carry on jobs with the ability to save data can become crucial for any testing environment as the testing phase matures.

The Docker agent of TestProject comes with this feature built in. You can easily start images that run for indefinite time & you can save the data with the help of attached volumes in case a running container fails. To get started aforementioned we need the TP_API_KEY to grant access to the project & an TP_AGENT_ALIAS to set a custom name for the agent.

When starting an instance with these variables, the agent is automatically registered to the account. This name can be referred to if you want to view the agent in your account.

Ephemeral Instances

In order to have test environments that resemble production environments we can either configure it at the source code level, or have tests run on actual servers with the dependencies like db etc. installed.

The story at the source code level brings unwanted configurations to the code, making it hard to maintain with newer updates & bug fixes. However, running it on an actual hardware is also a burnout as stuff can get overwhelmed pretty quick & comes with a lot of setup and maintenance overheads. In addition, since resources are shared among tests we can only run them one at a time to ensure they don’t interfere with each other’s executions.

services:
  testproject-agent:
    image: testproject/agent:latest
    container_name: testproject-agent
    depends_on:
      - chrome
      - firefox
    volumes:
      - /Users/qatechtools/Documents/TestAgent:/var/testproject/agent \
    environment:
      TP_AGENT_ALIAS: "QaTechTools"
      TP_JOB_ID: "job_id"
      TP_API_KEY: YourAPIKEY, "testParameters": [{ "data": [{ "ApplicationURL": "https://example.testproject.io/web", "FirstName": "John", "LastName": "Travolta"}]}]}'
      CHROME: "chrome:4444"
      FIREFOX: "firefox:4444"
  chrome:
    image: selenium/standalone-chrome
    shm_size: '1gb'
  firefox:
    image: selenium/standalone-firefox
    shm_size: '1gb'

Let’s have a look at Docker Compose which enables us to get the best of both worlds. It makes it easier to replicate the parts we have in environments & create them in the form of containerized solutions. We get the freedom to test in a real physical environment.

The TestProject Agent is responsible for handling the test cases with the given api_key & job_id. The Docker compose file also sets up multiple browsers to run the tests on. After running the test it exits so that any cache left is cleared.

Now, let’s run this Docker compose file from the terminal.

docker-compose -f /Users/qatechtools/Documents/test-agent.yaml up -d

Since all the image were already available in my system , it started pretty quickly.

You can verify you agent is ready by visiting Manage Agent page.