WSO2

How to automate WSO2 product configuration testing with Postman

Bas Verhoog
Integration Consultant
How to automate WSO2 product configuration testing with Postman
Scroll

2020120201203When deploying a WSO2 product, automating the deployment and configuration makes a lot of sense: it cuts down on deployment times, is less fault-sensitive and enables more people to do deployments. The important question then is whether everything has been completed correctly and your configurations have been applied as you had expected. In order to check this, we suggest implementing automated testing. In this blog, I will explain how the basics of automated testing can be done with a WSO2 deployment.

Setting up

In order to create and run these tests, we need to do some setup. This consists of two major components: knowing which configurations you want to test and installing software to run the tests and output results.

In WSO2, the product includes a number of SOAP-based admin services, which you can call to read, create, edit and delete configurations. We’ll use the UserAdmin service to create a user profile, validate its properties and then delete it. In order to do so, as we also do in our Connext Platform, a managed WSO2 cloud platform, we use Postman.

In order to know which operations you can perform on the admin services, you can use SoapUI. I have written another blog where I describe that process, called “How to use WSO2 admin services for testing .”

Adding user

In Postman, create a new request. I’ll assume you’re running WSO2 locally; if you have the know-how to set it up differently, you know which domain to use.

In the Authorization tab, use Basic Auth. The default WSO2 username and password are both admin.

Then, grab the payload from SoapUI and fill in the variables you want to send to the WSO2 service.

It should look something like the following:

Figure 1- Example Admin Service call

Figure 1: Example Admin Service call

When you run this request, it will add the user to the primary WSO2 userstore. However, you can only test this once: running this request again will, of course, return an error. Let’s make it so we also delete this user after this request.\

Basically, all we need to do is follow the same steps: copy the payload of the deleteUser operation from SoapUI. Since we are using the same service, we can copy the URL from our first request and edit the username to be the same as above (in this case, yenlo-user). Then, when we run the entire collection, which you can do, try the Runner! we don’t need to delete the user manually afterwards.

Verifying results

In the Postman Tests tab, you can write JavaScript code to verify the response. You have access to the server’s response, allowing you to parse the result and verify the contents. In order to parse XML, though, it’s best to first convert it to JSON. Luckily, Postman includes the xml2js NPM module for that in its Sandbox. Your script should look something like the image below shows. We are looking for a response with element addUserResponse having a nil attribute with the value true, as we expect from WSO2 in this case.

Figure 2- Parsing and verifying the servers response

Figure 2: Parsing and verifying the server’s response

Conclusion

Using a similar approach, you can validate and verify configuration and connectivity, like we do in our Connext Platform. This allows for catching errors early on, before they can have any impact on a running environment. Platform stability and predictability will be improved, as well as the confidence you and your users have in the platform.

Any questions after reading this blog? Feel free to leave a comment below. In case you need support, discover our WSO2 support options or contact us for advice.

{{cta(‘ac5750e0-36c6-4c0f-9f41-624f8794a17e’,’justifycenter’)}}