Automating Peer-to-Peer Communication in Selenium (Part 1 of 2)

Author: Tejaswini Simha

At Last Mile, we believe in solving customer problems, even if conventional wisdom says it can not be done.

In this series, we discuss how we have gone out and solved specific problems for our customers, oftentimes innovatively, definitely effectually, and have improved their approach and coverage achieved during testing.

The Context

The customer, a Broadband PTT (Push to talk) product organization, had an integrated dispatch console application to enable centralized communication with an organizations’ on-field contacts. The dispatch console includes GPS-based location mapping, call recording, and PTT user status (presence). The web dispatcher module is architected around Angular JS and Pouch DB. The Android application is native and developed in Java.

The application had interrupt driven peer-to-peer communication between dispatcher instances running on separate machines and also between dispatcher and mobile devices.  For automation to be effective, this needed to be handled in Selenium across browsers running on separate machines and Android applications on devices.

Over two parts, we will explain how we re-purposed Selenium Grid and tailored our automation framework to  allow seamless call flows and synchronization across different web dispatchers and mobile applications.

Architectural Choices

There were two architecture options available:

  1. Centralized Approach
    A single test script that controls the complete end to end scenario.  It should synchronize across the various applications by switching context from one application to another.
  2. Decentralized Approach
    Run multiple instances test scripts (applications) deployed on each machine and android device.  Synchronization would be achieved through fixed waits. In other words, each of the deployed applications (automated test scripts) would wait for a definite time for an event to occur.

The decentralized architecture was ruled out because of the possible synchronization headaches.  Implementing synchronization across multiple web dispatchers and devices by using waits is not resilient or future proof. This solution also generated a lot of false negatives due to the nature of the application.  The client chose this approach and found automation ineffective. They were stymied as a centralized approach was not possible in Selenium, as it stood.

Last Mile implemented the centralized architecture using a combination of built-in Selenium features, re-purposing Selenium Grid for handling script control issues and by implementing custom code in the Last Mile automation framework.  This solution enabled the customer to automate peer-to-peer communication in an interrupt driven mode.

(Read about how the problem was solved and how effective the approach was in next part.)

[To Be Continued]