C-GRID is a tool that is capable of running automation jobs in parallel across multiple machines (EC2 / Local Desktops) providing real time updates and comprehensive run reports.


Components –

C-GRID is made up of 3 major components –

  • Controller
  • Beanstalk queue
  • Clients

Functionality Breakup 


This module plays an important part in the C-GRID setup. The controller is responsible for handling the whole execution flow right from the point of allowing users to choose test cases/test suites to be executed to the point where the results of a particular run are displayed.

The salient features of the controller are listed below –

  • Providing A UI For Test Selection

The controller is hosted on a Django server and is the starting point for all C-GRID test executions. The user begins by creating a session by choosing the module to be tested along with other parameters like type of test to run, environment on which the test is to be executed, particular test suites/test cases that need to be executed. Once a session is created, the session can be run by clicking on the run command. When a run is active, the live run statistics of the page are displayed which provides a count of queued, passed, failed and skipped test cases.

  • Controlling the Beanstalk Queue

Once a session has been started, the controller creates a unique run id for that session and creates a new queue on beanstalk that bears the same name as the runId. Besides this, the controller also adds jobs to the default beanstalk queue that represent individual test cases/test suites as chosen by the user in the UI.

  • Providing the ability to abort tests

Many a time, it may be required to abort a test midway. This functionality is provided by the controller at the live reporting screen through an “Abort” button. When this button is clicked the controller deletes the runId queue and all unreserved jobs from the default beanstalk queue and waits for any clients that are currently executing jobs to graciously quit the job and submit their reports for that particular run.

More about this behavior can be seen in the abort flow diagram shown below.

  • Displaying the results of test execution

During test execution, the complete details of the execution of each test case is also provided by the controller. This page is automatically updated as the session  execution proceeds.


Queueing Mechanism – Beanstalk

Beanstalk plays the part of a communication medium between the controller and the clients by allowing an exchange of control messages and test execution messages.Beanstalk was chosen for the queuing system because it is a lightweight queue that is very fast and consumes minimal CPU while providing easy setup and support for multiple languages.

In a typical run, there are two queues that are of interest.

  • Default Queue

As the name itself suggests, this is the default queue of beanstalk – the one that is automatically created when the beanstalk server starts up. The controller uses this queue to add all the test suites that need to be executed so that it can be consumed by the clients.

  • RunId queue

This is the special queue that is created by the controller on a per run basis. This queue is referred to by all clients to ensure that the given run is still active and has not been aborted. When the run is aborted by the user, the controller deletes this queue thereby signalling to all clients that all running jobs need to be terminated.


The consumers run on client boxes which are typically running the Windows OS. The consumer is a Python script that constantly polls beanstalk for the presence of a runId queue. If the consumer finds that there is such a queue that has been created by the controller, the consumer checks the default queue for test jobs which would have been added by the consumer. When a job is found, a client marks that job as reserved and proceeds to execute the job in a child thread. During job execution, the main thread constantly checks to see if the runId queue still exists. If yes, the job execution in the child thread proceeds normally. In the event that the runId queue is not present, the consumer realizes that the job has been aborted by the user. Thus, it sends the child thread a command to gracefully exit. The child does the exit gracefully and sends the report back to the controller.

The test suite on the client is written in Java employing Selenium and TestNG though test modules in other languages can also be easily incorporated with C-GRID. Once a job is available for execution, the child thread checks out the latest version of the code from SVN and compiles and runs the tests using maven.


Architecture of C-GRID



The Flow Of Control

  • Normal Execution

The following diagram shows the normal flow that C-GRID follows when a job is scheduled. For the sake of simplicity just one client is used here.


  • Abort Flow

One of the import features of C-GRID is the ability to abort a test run. The following diagram shows the abort flow when the abort command is passed while the test is being executed.




C-GRID has proven to be a powerful parallel automation tool at Capillary Technologies. The benefits it has provided in terms of time savings when executing large test suites has helped the QA team at Capillary provide faster turn around times for production and staging releases. Also, the ability to run the clients on both EC2 and local test machines is a powerful feature of the tool.

Here is a table that shows the time savings we’ve been able to achieve with C-GRID.

Test Suite Time without C-GRID (hours) Time with C-GRID(hours)
Data Import Framework 9 to 10 2.5 to 3
Customer Loyalty Test Framework 1.5 to 2 0.5

From the table above it can be seen that time savings of about 75% have been achieved due to the use of the C-GRID.

Besides this, the easy integration of any new module to be tested and the flexibility to integrate any type of test suite that can benefit from parallel execution renders this an essential tool for any testing team.