Skip to main content

Interaction Processor

io.resttestgen.implementation.interactionprocessor;

The abstract class InteractionProcessor defines an interface for processing test interactions. Within this class we find two methods: canProcess, to check whether an interaction is suitable for processing; process used to execute the processing of the interaction.

Graph Interaction Processor​

This is an implementation of the abstract class InteractionProcessor that updates a dependency graph between API operations based on the responses received in tests. First of all, it is checked whether the interaction can be processed. In fact, only interactions that have been successfully executed are processed. After that, the interaction is processed. The operation is marked as tested in the dependency graph (OperationDependencyGraph). The response body is analysed to identify parameters that may satisfy dependencies of other operations, and the graph is updated, marking detected dependencies as "satisfied".

JSON Parser Interaction Processor​

This component takes care of interpreting and converting the JSON responses received from the API into an internal parameter structure. This makes the response data more easily usable for subsequent tests.

First, it is checked whether the response of the interaction can be processed. A response is considered valid if the test was successful and the response body is not empty and has an acceptable size (between 1byte and 1MB).
If these conditions are met, then an attempt is made to convert the response into a JSON object and, if the conversion is successful, the internal structure is updated with the extracted data. If the conversion, however, fails, the processor checks whether the content of the response is declared as JSON in the content-type headers. If yes, it records a warning in the logs, indicating that the content may be corrupt or malformed.

NLP Interaction Processor​

This interaction processor uses natural language processing (NLP) to extract rules from error messages returned by the server. The idea behind this component is to analyse the messages returned in response to incorrect API requests (400 status code) to extract useful information and convert this data into testable rules.

First, it is checked whether the interaction is processable. Then it is checked whether the processor is active, whether the interaction has been executed and whether the response has a 400 status code.
The body of the response is then analysed and if a string with the name “message” is found, it is sent to the NLP module (RuleExtractorProxy) to extract any rules implicit in the server message.
The response headers are also analysed. If the latter does not contain a content-type header, the processor still attempts to extract rules based on the entire content of the response.
The extracted rules are stored in a set (rulesFromServerMessage).
This interaction processor makes it possible to dynamically learn new validation rules based on the errors generated by the server and can be used to improve automatic tests by adapting them to the actual responses of the tested system.

Request Dictionary Interaction Processor​

This interaction processor stores the parameters of test requests in a global and local dictionary. The objective is to construct and maintain a dictionary of the request parameters used in tests, so that they can be reused in future tests. First, it is checked whether the interaction is processable, i.e. whether it was successfully executed and whether the status code is 200 or 201. If this is satisfied, then the request parameters are processed. After that, the interaction is processed. The parameters are taken from the request and used in the interaction. Leaf parameters and those with an assigned value are filtered out. For each valid parameter, an entry is created and added to the global dictionary. It is also possible to set up a local dictionary.

Response Dictionary Interaction Processor​

This interaction processor stores the parameters of API responses in a global dictionary and a local dictionary. The aim is to collect and store the parameter values in the body of the tested API responses in order to be able to reuse them in future tests. Again, it is checked whether the interaction is processable, i.e. whether it was successfully executed and whether the response has a positive status code, i.e. 200 or 201. It is also checked whether the response body isn’t empty. If all conditions are met, then the response body is analysed and the LeafParameters are extracted, null values are excluded, and for each valid parameter an entry is created and added to the global dictionary. If there is also a local dictionary, the entry is also added there.