Testing proprietary systems

There are times when you have to integrate into a proprietary or legacy system, most of the time, using an API to implement the integration.

Testing such integration with a proprietary or legacy system can be complex, if possible at all, since most of the time, the proprietary system is not based on an open-source protocol and mocking the internals of the system is not an option.

Examples of such proprietary or legacy systems are banking software and telephony systems.

To test such projects, you are only left with live tests, which means using the live system, sometimes the system in the production environment, to simulate use cases and check that your application behaves as expected.

But live testing shouldn't be an option at all. Here are some of the downsides of live testing

• they are not automated

• they cannot be run as part of a CI/CD pipeline

• they are error-prone

• they are time-consuming

PCAP Replay

Looking for any tools that can help here, I came across the excellent project Wiresham (https://github.com/abstracta/wiresham/) a simple TCP service mocking tool for replaying tcpdump or Wireshark captured service traffic.

You can check project details on how to set up Wiresham on your application.

The required tools are:

• tcpdump

• wiresham

Following are the steps needed to capture live traffic, prepare dump flows and set up replays in your test case.

Capture live traffic with tcpdump

To capture live traffic we need the external proprietary system and our application.

Some of the important things to consider on capturing live traffic:

1. Check which ports are involved. For some applications, ports might include signaling and media

2. Start tcpdump for each of the discovered ports. Make sure you define the proper network interface, for example, if traffic goes through VPN, start tcpdump on the VPN interface.

For example:
sudo tcpdump port 450 -i ppp0 -w jtapi_450.pcap

Dump flow files with wiresham

Use standalone wiresham to dump data from pcap to a simple flow file that later will be used in the integration test.

It is important to specify the ip address of the service that we want to mock using the "-a" option, this way wiresham can properly prepare the dump flow.
Using the "-a" option allows Wiresham to identify which tcp packets are coming from the mocked service, and prepare the flow accordingly - remember we need to mock the external service and have our application receive any request/response from the mocked service.

If for example the ip address of the server we need to mock is 10.100.26.31 we need to run the command:

java -jar ./wiresham-0.4.3-standalone.jar -d dump-450.yml -a 10.100.26.31 jtapi_450.pcap

-a (--server-address) ip address : When using a Wireshark generated JSON dump or PCAP file, this parameter specifies the IP address which identifies the service to be virtualized
...
-d (--dump-file) .yml file : File path to dump loaded flow config. The virtual service will not be started when this option is specified. This option makes sense when a Wireshark JSON file is used for config to dump a simplified and smaller file and then manually tune it if needed

The result of the operation will be yaml files that will be used in the test.

Integration test

To properly set up an integration test we need wiresham dependency to use the tools such as VirtualTcpService.

The test will have to instantiate as many VirtualTcpService tools as the number of flow files prepared earlier.

The VirtualTcpService tools need to be set with the proper port, flow file and started.

In the test, reference the mocked remote service using the localhost ip address and the service port.

Avaya Application Enablement Services Example

Avaya AES is one of the proprietary systems that are very complicated to mock and prepare tests for an application that uses JTAPI library to integrate with the service.

Using the tcpdump and wiresham project, we can capture live traffic and then prepare flows to be used in integration test cases for applications using JTAPI.

Following, you will see the steps needed how to capture JTAPI traffic and replay it in a test case.

Capture with tcpdump

AES traffic uses the following two ports

• TCP/450

• TCP/1050

To prepare the test we first need to start tcpdump capture and second start the JTAPI application and connect to AES server.

Use two different tcpdump process to capture AES real traffic

• sudo tcpdump port 450 -i ppp0 -w jtapi_450.pcap

• sudo tcpdump port 1050 -i ppp0 -w jtapi_1050.pcap

Depending on your needs, you can capture just the AES connection, register a station for events and capture events.

Dump flow files

Use standalone wiresham to dump data from pcap to simple flow file.

Make sure to specify the ip address of the Avaya AES server using the "-a" option, which in the example is 10.100.26.31.

• java -jar ./wiresham-0.4.3-standalone.jar -d dump-450.yml -a 10.100.26.31 jtapi_450.pcap

• java -jar ./wiresham-0.4.3-standalone.jar -d dump-1050.yml -a 10.100.26.31 jtapi_1050.pcap

The result of the operation will be two files:

• dump-450.yml

• dump-1050.yml

Prepare the test

We need to prepare the test with two instances of VirtualTcpService, set their port to 450 and 1050 and set the flow to the relevant files.

private VirtualTcpService service450 = new VirtualTcpService();
private VirtualTcpService service1050 = new VirtualTcpService();

@BeforeEach
public void setUp() throws Exception {
service450.setPort(450);
service450.setFlow(loadFlow("/dump-450.yml"));
service450.start();

service1050.setPort(1050);
service1050.setFlow(loadFlow("/dump-1050.yml"));
service1050.start();
}

The above setup is everything we need to have the test to mock the JTAPI link to Avaya AES.

Leave your comments and suggestions below