Photo by Brett Jordan on Unsplash

Automated tests for proprietary systems

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

Testing such an integration with a proprietary or legacy system can be complex, if possible at all, since most of the times, the proprietart 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 use the live system, some times 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 accross the excellent project Wiresham ( a simple TCP service mocking tool for replaying tcpdump or Wireshark captured service traffic.

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

The required tools are:

Following are the steps needed to capture live traffic, prepare dump flows and setup 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 signalling 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 simple flow file that later will be use 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 examples the ip address of the server we need to mock is we need to run the command:

java -jar ./wiresham-0.4.3-standalone.jar -d dump-450.yml -a 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 yml files that will be used in the test.

Integration test

To properly setup an integration test we need wiresham dependency in order 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 needs to be set with the proper port, flow file and started.

In the test, reference to 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 is 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 for 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, registering station for events and capturing 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

  • java -jar ./wiresham-0.4.3-standalone.jar -d dump-450.yml -a jtapi_450.pcap
  • java -jar ./wiresham-0.4.3-standalone.jar -d dump-1050.yml -a 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();

public void setUp() throws Exception {


The above setup is everything we need to have the application setup the link to Avaya AES.

This is what we use for the testsuite of JTapiLib, a simple JTAPI library for Spring boot projects that can be used in any project that needs to integrate with Avaya AES, and JtapiLogger a JTAPI application that provides a REST API for processing station events.

You can contact us here