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.
Dirk
More information about the london.pm
mailing list