Planet Test Automation: First Steps, Part 4: Automating REST/SOAP API Testing

3 min readDec 10, 2019

Now we talk about API testing. Our plan is to touch both SOAP and REST endpoints in some real-life scenario.

We will use real system OpenMRS (https://www.openmrs.org/). One of its benefits for us (besides widespreaded use across the globe) is availability of accessible demo (https://www.openmrs.org/demo/) as well as one-click-to-install version that may be downloaded and launched locally.

As you may noticed earlier we try to use 3rd party systems as applications under test (AUTs) rather than our own home-grown AUTs to make demonstration closer to real life. In the real life the application always have some problems and pitfalls challenging the automation engineer.

OpenMRS has REST api and we will utilize it.

It has no SOAP, but we will use another application with SOAP interface that will help make our testing better. It is SpiraTeam. One of its features is Defect Tracking. So we plan to check consistency of data before running the test and, if there is a problem, create an incident in SpiraTeam. So QA person will see that something needs to be corrected before running automated tests again.

Initially we have 3 scenarios planned S01_Login S02_CreatePatient S03_CreateMergePatient. But only one of them is currently implemented (S03). Please, note that we didn't start from first (S01). We had a planning stage and identified several scenarios worth implementing. Then we have chosen one of them. It is promising: it takes much time from manual tester while still easy to automate.

It is common mistake to always start implementation of tests from first scenario and then move on. Always think what will bring you more benefits and save maximum time.

So here we implement S03 first. Here we test the merge patient feature. When filling a new patient data in OpenMRS the system checks matching existing patient and advises to merge entries to avoid duplicates. It looks like that:

Our goal is to test this logic. So we plan to prepare patients DB to have single entry of a patient with specified name, to then register it again and validate the merge prompt:

The block in Preparing Data section uses REST API to ensure that patient with specific name exists once in the target system and gets its OpenMRS ID for further merge.

If two or more patients with same name already exist, we cannot launch the test. In this case we stop test execution and fill bug about inconsistent data in the database. We use SOAP API to automatically fill a bug in SpiraTeam.

During the course of the implementation we would also consider a couple of specific topics:

1. One is a version of API to choose. It is common to have APIs of different generations. And latest is not always the best for some purpose. We will talk about it.

2. Another is a way to read documentation about web services quicker. Sometimes it is big and we demonstrate a couple of ways on how to quickly start without complete reading of docs.