ANTS (Design & Development)

January 2, 2026

TL;DR

With CATS automating single-radio integration testing and replacing much of the functionality previously handled by BTS, the next major testing gap to address was inter-radio communication. ANTS is designed to fill this gap by focusing exclusively on how multiple radios communicate and interact with one another, and its primary goal mirrors that of CATS: reduce the risk of software regressions going unnoticed and spiraling into much bigger issues. Due to the increased scope and complexity of multi-radio testing, ANTS’s development has been split across my final two internship semesters at MAS, with the first phase centered on designing and implementing the system’s core architecture. ANTS operates over MAS’s local network using a three-layer design consisting of a Pytest-based test layer, a middleware coordination layer, and node machines that are connected directly to radios; these layers communicate and coordinate with each other through WebSocket connections using custom messages and a shared API. Like CATS, ANTS is intended to integrate with GitLab CI; however, because these tests are significantly more complex and time-consuming, these pipelines will be limited to running nightly, providing results to engineers the following morning. With the conclusion of my second semester at MAS, ANTS’s design has been implemented and largely finalized, setting the stage for integrating this test suite into our pipelines and firmware development processes.

Background

With CATS having addressed the need for single-radio integration tests, the next logical step was to move up the testing pyramid and implement a system for performing automated end-to-end testing of inter-radio communication.

While CATS’s ability to automate integration tests through GitLab CI has been effective in reducing the risk of firmware regressions at the individual radio level, this was not yet the case for scenarios involving multiple radios interacting with one another. Bringing the same level of automation to end-to-end testing comes with significant benefits, particularly in catching more complex failures earlier in the development process. Building a new end-to-end testing suite would also allow MAS to retire the legacy BTS testing software, which has grown unreliable and increasingly difficult to maintain as engineers have prioritized more important tasks; additionally, ANTS allows us to start off with a clean slate with a focused purpose, rather than trying to handle both integration and end-to-end testing in a single, manually operated application. Building on several of the ideas and constructs developed for CATS, I set out to design a new system specifically tailored to this task.

Overall Design and Operation

A Three-Layer System

To coordinate and test multiple radios simultaneously, ANTS could not follow the same one-machine approach as CATS. In addition to the need for multiple radios, all of which require their own host computer, the behaviors targeted by ANTS require interaction with a separate piece of software (which I will refer to as M) that only runs on Windows; this is especially problematic for MAS’s development team, as most engineers use Linux as their main environment. To accommodate these constraints, ANTS is designed as a three-layer system, with each layer serving a distinct role:

The testing layer is a Pytest-based application responsible for orchestrating tests; it achieves this by issuing commands to the radios and asserting they behave as expected.
The node layer consists of all radios present in the test session, each connected to their own Windows machine; nodes are primarily responsible for executing actions through the M software when commanded to by the testing layer and sending log messages generated by the radios back for analysis.
Sitting between these layers is a middleware application that coordinates all WebSocket connections within the ANTS Network, implements some additional logic relevant to testing, and forwards messages to their appropriate destinations.

Shown below is a diagram that illustrates the way in which these layers will operate to form a cohesive testing environment; note that even though the testing layer and middleware are separate entities, they can be run on the same machine:

The ANTS API

The ANTS API provides a multitude of messages and objects for sending critical data relevant to testing; to keep everything on the same page, the API is bundled into a Python package and shared between all layers of the ANTS testing suite. When Pytest wants to send a message to a node, or vice versa, the sender constructs one of the Python message objects provided by the ANTS API, pickles it into a serialized format using Python’s pickle package (say that three times fast), and sends it via a WebSocket to the ANTS Middleware to be routed to its intended destination; after the message arrives at the destination, it is then de-pickled and handled by the destination layer. While the approach of sending serialized Python objects is considered somewhat insecure, as it can result in arbitrary code execution when deserializing an object, I thought it was appropriate for this use case, for this software will strictly be operating within MAS’s local network; furthermore, the benefits of being able to use these shared objects in exactly the same way across all layers outweighs the downsides regarding security in this case.

UML diagrams that illustrate the full scope of messages and objects contained within the ANTS API:

Executing Test Sessions

With its multi-layer architecture, beginning a test session in ANTS involves setting up and coordinating multiple machines over the ANTS Network. The process begins by connecting all radio-connected node machines to the ANTS Middleware, which verifies that each node has the correct versions of both the ANTS API and M software before allowing it to join. Once all nodes are registered, a Pytest instance is launched and automatically connects to the Middleware; after confirming that the Pytest instance is properly configured, the ANTS Middleware registers the instance internally and temporarily blocks new node connections until the test session concludes. In the future, GitLab CI pipelines are intended to handle much of this setup automatically, streamlining this process and providing developers with simplified controls through GitLab’s interface.

A diagram that illustrates the steps of registering all devices in the ANTS Network and running a test session.

Next Steps

With my second semester at MAS coming to an end, I am happy to report that the design and overall functionality of ANTS is, for the most part, implemented and finalized. Due to the considerable effort required to get a multi-radio system to a fully operational state, the ANTS project has been split up into two semesters worth of work. When I begin my third and final internship semester at MAS, I will begin to focus on getting ANTS deployed to the machines that will use it, as well as writing and executing the first batch of end-to-end tests for our radio’s firmware.