Test Coverage for our REST API

This week, the topic of REST API Test Coverage was raised in both the PM Team and QA Support Team calls.

Key Concerns:

  • Historically, doing manual tests of our REST API delays our Platform releases (example of manual tests here).
  • There are some existing REST WS tests, like these (which are buried and hard to find), but it’s not clear how much coverage our REST API has.
  • Given that our REST API is something ALL OpenMRS system users leverage, we should feel confident in our coverage of REST WS.

So, we talked about the need for more REST API test coverage in the Platform Team call today. Here are the key takeaways and next steps:

  • Key Points:

  • Action Items:

    • First: Platform Team Members (e.g. @dkayiwa, others?) to take a dozen of these tests, i.d. most critical ones, cross-check that these exist in the existing RESTWS tests. Then, create tickets for those that are left out and still need to be added in to the RESTWS module.
    • Then: QA Support Team Members can write tests for those that are missing.

Here’s the 15 min discussion of interest (I cropped this link so you don’t have to listen to the full hour unless you want to): 15 minute recording of REST API Test Coverage

@dkayiwa @ibacher @burke @tendomart did I cover that alright? Anything to add?

CC @christine @kdaud @sharif @pmanko @mozzy

1 Like

I haven’t studied this in too much detail when it comes to REST API tests, one thing I would like to know is whether there is any automated tests(testing) for the module ?

This suggests to me setting up automated configuration within the module and have automated tests written especially for critical functionalities. @ibacher @dkayiwa @sharif @bistenes @mksd does Selenium or Cypress apply in this case? If yes, which one would be more useful to achieve the goal in a more light-weight way?

@grace @dkayiwa would be a good idea to have these tickets on our QA-Kanban-Board distinctively labelled for members to pick them up and work on them.

1 Like

Fork and clone the module. Then run mvn clean install, and tell us if this answers your question. :slight_smile:

No, because it is not user interface functionality.


Hello @dkayiwa what would be the best approach in server url while carryout testing these rest Api end points, Using local instance or using cloud server like qa or demo since will be using postman client for querying Rest calls, GET, POST

Have also seen this rest client class that was already implemented acting as util class for rest calls.However am still skeptical whether we might need some more dependencies to cater for rest utils. If we are to write automated rest calls which module among qaframework, referenceapplication -distro or uitestframwork would be better to have these functionalities?

You’re absolutely right.

1 Like

@sharif here is an example of tests in that spreadsheet that already exist in the module:



And those tests run automatically for each pull request.

It is basing on the above that i conclude that our efforts are better spent on ensuring that each of the tests in that spreadsheet has a corresponding test in the module.


Ohh we simply mock a desired get/post request :ok_hand:

Thanks alot for your clarification , we have a clear direction now

1 Like

@ibacher since the future for Platform is fhir first does this apply for fhir as well ?

Yes, though we have a pretty exhaustive suite of automated tests for the FHIR2 module already. See here for example.


We have used cypress in a few instance to test the REST API. Here are some examples:

  • Login at location:
  • Retrieve login locations:

Ohh Awesome ,Thanks @cioan , and well be back its been quite some time seeing your response :slightly_smiling_face:

1 Like

Wow this is good to see and emulate

Update: our QA Support Team is considering Swagger, Karate, Jmeter, or Postman to support our API Test approach.

@christine @kdaud @sharif can you provide further info about this, and then perhaps interested parties in this thread can also provide feedback?

1 Like

Also: @dkayiwa @burke @ibacher any updates on this action item from last week’s Platform Team call?

Platform Team Members (e.g. @dkayiwa, others?) to take a dozen of these tests , i.d. most critical ones, cross-check that these exist in the existing RESTWS tests. Then, create tickets for those that are left out and still need to be added in to the RESTWS module.

The QA support team lead @christine is keen to see these tickets so we can delegate to support team contributors.

@grace also inquiring about timelines , would love to see this coincide with alpha and beta testing

@sharif @tendomart Cypress is for testing user interfaces. @dkayiwa is right. I imagine that @cioan wrote that test in Cypress only because we were already using Cypress to do E2E testing of something with an interface, and the REST API test was tacked on. Don’t use Cypress for this.


Great update from @dkayiwa on the Platform Team call today:

The Platform Team folks have gone through all the Platform 2.4.0 REST-WS endpoint tests in this spreadsheet, and they have identified all the ones that already have test coverage. This uncovered that 14 of 79 API use cases still need automated test coverage. :tada:

You can see how in the spreadsheet, they have linked the API cases to the specific area with the test coverage; these examples can be used to assist contributors who want to work on the remaining coverage gaps: image

@christine @kdaud @sharif - what do you think, should we create Jira Issues for each of the 14 remaining things that still need coverage?


Oh sure, i think its worth creating jira issues for the remaining un covered tests.

While creating tickets to cover the remaining REST API cases, I notice that I can not move any ticket to READY FOR WORK on QA Kanban Board. Most probably I am less privileged on the RESTWS module tracked by Jira and guessing @grace is the best person to help here!

@kdaud I’ve updated your privileges, you should now be unblocked :slight_smile:

1 Like