Using a REST request emulator in a real-life project

We utilize the micro service architecture more and more often while developing software nowadays. It allows us not only to speed the development up, but also to make the end product more agile and easy to scale.

A large governmental enterprise that processes a huge amount of various documents has recently approached us. We had to organize the autonomous testing process of key subsystems, which comprise the automated information system. Moreover, we couldn’t use an out-of-box solution (client’s specification), so we had to develop a custom tool that would satisfy the client’s requirements.

How have we managed it?

Initially we studied the system specification and designed a subsystem cooperation scheme It allowed us to determine the main requirements and formulate the project charter for the future subsystem emulator.

The document processing workflow looked like this:

Have a Project in Mind?

We have been working on performance testing projects since 2008.

Drop us a line to find out what our team can do for you.

The automated information system can be pictured like that:

Subsystem A – it is a transport subsystem that connects all subsystems

Subsystem B, C, D, n – these subsystems, each of which is responsible for processing a specific data set

REST queries are responsible for the subsystem communication.

Here is an example of a subsystem communication:

We’ve chosen JAVA as the language of the subsystem emulator and used the following subsystem and emulator cooperation architecture:

The emulator has a user-friendly native interface, as well as the terminal run option.

The emulator’s interface allows to:

Switch the software modules, such as the logger, the emulator, the retranslator on and off;
Configure the emulator;
Monitor the subsystem load intensity.

Thanks to its universality and agility, the emulator can be used in the following scenarios:

It’s necessary to analyze the system calling protocol;
It’s required to partly emulate some certain system behavior;
It’s obligatory to emulate a non-existent or broken system.

We’ve developed a user manual for the client during the project.

Which challenges has our team faced during the project?

The testing team has encountered the following problems while analyzing the client’s requirements to the emulator:

Subsystem isolation during the functional testing. In fact, we had to develop the emulator in such a way, so that it could substitute the subsystem in use. For this purpose, we’ve developed a log collection algorithm for the subsystem. Taking into account the log analysis results, the testing team composes the correct and incorrect answers beforehand and feeds them to the emulator. As a result, the emulator already has the required answer, when the subsystem calls to it.

System support for other teams that concurrently work on software, administration or monitoring. We’ve added a retranslation module to the emulator, which allows to send the queries from one subsystem to another and to send an answer in case the question has not come from the same team.

The agile behavior – the ability to configure the emulator. We’ve developed the possibilities to configure the emulator’s work, e.g. one can set the response time or forbid an answer or receive a custom answer. Such a functionality stands for the flexibility in evaluating the subsystem’s quality.

Query and answer logging. Our emulator not only collects the subsystem communication logs, but also their statistics and the amount for the used documents and queries. This information is in the log file and in the program’s interface.