Testing AMQP-based APIs
By Ivan Nikanorov, QA Engineer at Rosberry
We keep on sharing our experiences in the realm of mobile app testing. If you’ve been a follower of our publication for long, you should remember that some time ago we already started telling about our use of AMQP protocol and RabbitMQ. We explained why we couldn’t employ standard methods to inspect traffic within the project we had at that time.
In today’s mini-article we will have a closer look at another case many QA guys might often face i.e. the backend is ready for testing whereas the app itself is still under development. In this situation in order to test the backend we have to simulate the work of the client side. With the HTTP API we will hardly have any problems as we can send a request to a server from the terminal using cURL or some specific app for example a widely-known Postman. But testing of AMQP requests is a different story. The choice is not that wide, but luckily we’ve found some tools to help us solve this problem.
We bumped into Kurier on github. It allows to check message queues, exchangers, keys, etc. Also it saves all the previous call requests with an option to repeat them. So, let’s have another go at how we can send and get call requests from the server simulating sending and receiving requests from an app.
The tool actually is a cross-platform Python-based app which we managed to successfully get built to work under macOSX and Ubuntu.
Requirements for the build:
- Python >= 3.7
- wxPython >= 4.0
The app window looks the following way:
At the left you will find the history of successful requests in rows. Choosing any row to send a server request you will get all necessary fields filled out. To filter successful requests the client has at its disposal a search feature based on history.
The request itself is shown in the Request field whereas the response after pushing the Send button will arrive in the Response field.
Our server’s security mechanism provides for only one user to listen to the server messages which are meant for him. So to make testing convenient we created one multi-user account on the server with the right to access all the messages. It allows to use only one connection string for the requests from different users.
One more feature of this AMQP-client is that it allows to listen to the server-side response with a specific routing key. To make it possible you should leave a Message body empty and press Send. The button will change its status to ‘Cancel’ and will continue like this.
After the AMQP-client gets the response with the routing key needed, the Send button returns to its origin, and you get a received response in the Response field.
So, using the tool we can test the AMQP-based backend without a mobile app at all. The advantages of this are:
- finding and fixing bugs at early stages of infrastructure development;
- checking for complex and negative scenarios;
- checking for safety issues.
Additional benefits are that the tool itself is free and open-source which allows for possible modifications of AMQP-client and tailoring it to your own project and tasks.
The main disadvantage is the lack of feature to create collections and auto-tests like Postman offers.