When 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.
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 .”
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:
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.
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.