Testing message switch daemons

Dirk Koopman djk at tobit.co.uk
Thu Mar 14 10:13:57 GMT 2013

I have a message switch, rather long in the tooth, which is finally 
being allowed by management to be automatically tested. So I need a 
Test::xxx module of some kind that starts up a process (written in C), 
connects to that process twice (testing will be bidirectional) using TCP 
or UDP.

The switch has many "drivers". Msgs come in on one driver that handles 
some arcane "high level" (HL) binary format framed in one of several 
"low level"(LL) message framing styles. The message is normalised, 
routing decisions made, then sent out through one or more HL+LL driver 
interfaces. Each driver may (and usually will) de-normalise the message 
on output.

One common usage of the switch is to receive position reports in one of 
many formats (ETSI LIP, Motorola LRRP, NMEA (various) or one of several 
proprietary formats) and to output them to several interested parties, 
connected simultaneously, each connection expecting one of an EDI, JSON 
or XML version of each position report.

The general case will be:

0. Start up process with generated parameter file.
1. Send some data to the process on one connection.
2. Wait for the normalised message and Test it on the other connection.
*. Repeat 1 & 2, until happy.
*. Reverse direction of travel, then repeat 1 & 2 as before.
3. Kill process.

Then do the whole lot again for each driver. This switch has several 
"drivers" (something like 20) each of which will eventually need tests.

This tests each driver. Once this is done, one then needs to test "end 
to end", binary LL/HL driver to binary HL/LL driver.

A further issue is that any UDP "connection" may be running some kind of 
ARQ protocol which will need some handling underneath or "out of band" 
from the testing process (if that makes any sense).

Any suggestions for the best CPAN Test::xxx module to look at for this 
kind of job? Concise testing would be very nice.


More information about the london.pm mailing list