Automated Tests for the OCL Module?

Hi Team (especially CC’ing @moshon @hadijah315 @suruchi @jwnasambu),

As shown in OCLOMRS-1042, we have this re-occuring issue where errors happen at the time of trying to import concepts from OCL to an OMRS EMR by using the OCL Module.

This is quite a negative experience for implementers: You’ve done a bunch of work either in a CSV or in the Dictionary Manager, then you think you have all your concepts set up and ready to go, and you import them, and then… you discover a whole bunch of errors! We thought we had fixed this a few months ago, then it happened again at a critical moment right before a real-world implementation, which blocked the implementation from using the OCL Module for their site launch.

We should really have some automated test coverage in the OCL Module for this problem (kudos @michaelbontyes for this great point). That way if something changes that would cause the OCL Module to have a bunch of errors, we could fix it pro-actively, rather than only finding out about it after a user has had a bad experience. We do try to do regular manual testing, but this does not catch everything, and our PM resources are stretched thin.

Thank you to @moshon for working on the current bug. But to prevent this in the future, what can we do next?

  • @michaelbontyes has also already put together a set of test cases.
  • Could we use the QA Framework with Selenium to automate something via a Frontend test? Or is there a different approach?

CC @kdaud @burke


Seems like it’s more useful to do this without something like Selenium, as it can be done in a more light-weight way.

What we need is an established test dictionary in OCL we can use for this. We can then setup a process to:

  1. Cut a new release of the dictionary
  2. Install the dictionary into an OpenMRS instance using the OCL Subscription module
  3. Verify that the correct metadata is setup

This would definitely be something nice to have integrated in to the QA dashboard, even if it’s not quite using the same technologies.


Thank you @grace.

Ideally, the automated testing would cover in detail both the ability to populate/update a source in OCL, and the ability to import a dictionary in OpenMRS from OCL to improve stability and reliability.

Based on a set of mutualized test cases, it would make sure that all values/meta-values/mappings are correctly imported in an OCL source using the new CSV bulk import UI, and that a dictionary populated with that source is correctly imported in OpenMRS using the OCL subscription module. Otherwise, we would have to verify each term individually every time we have new terms/implementations, or for regression testing in both OCL sources and OpenMRS implementation in case of future releases.

@ibacher, do you think that such data-layer testing could even be useful for content management (like source and dictionary cloning) in the Dictionary manager as well?

CC’ing @mogoodrich

1 Like

I haven’t studied this in too much detail, but I agree with @ibacher that this doesn’t seem to be something that requires Selenium or front-end testing. I don’t know the nature of the bugs being discussed, but the three steps that @ibacher describes seems like the key things to test.

Take care! Mark

1 Like

@ibacher am so sorry for a bother! I kindly need your help on the steps listed above most especially the first 2. Kindly how to do I go about it?

Hi @jwnasambu,

Here are some additional details:

1. Cut a new release of the dictionary: for example use the latest release of this collection based on the test cases CSV

2. Install the dictionary into an OpenMRS instance using the OCL Subscription module (version 1.2.10 and above): Add the subscription link of the latest release of that collection

3. Verify that the correct metadata is setup: find a way to compare the content of the collection and its release with what was imported in OpenMRS (for each field of each concept)

Does it help?

@ibacher and @michaelbontyes thanks for the clear explanation. which Dictionary manager server are you running? Am using my local instance and as you can see I can’t see the release versions

alternatively, does running an sdk instance then follow the steps below work without following the first 2 listed steps above serve the purpose?

Steps to follow:

  • Login into the system
  • Go to Home Page
  • Click on configure Metadata
  • The System loads Manage configure metatadata page
  • Click on Manage OCL link
  • The system should load open concept lab
  • Click on setup subscription button
  • Add a subscription url
  • Enter subscription Token
  • Save the changes

Kindly I stand to be corrected. my comment above is just a thought.

They’d appear in the “Versions” box if any existed. You’d actually need to click on the “Create New Version” button to create a new version and marked it as released there.

1 Like

@ibacher thanks so much though I used a random Id but am glad we are on the same page as you can see on the screenshot below

@ibacher, @dkayiwa am stack on how to proceed with this issue! between the openmrs-ocl-client and the openmrs/openmrs-distro-oclqa repositories which one should I use for this ticket. I had already pushed the feature file on the openmrs-ocl-client before coming a cross the openmrs/openmrs-distro-oclqa repository. I wish to put things right.

I thought we established a while ago that our plan is to only stick to writing QA automation stuff in the OCL client repo itself (or in the OCL Module repo if the tests impact that module and not the webapp). Did that plan change?

This is a bit of a weird one… In my view, we already have a decent amount of testing in the OCL module itself, but this ticket is really about building testing so users of the OCL module have confidence that it works correctly (i.e., it’s part of what Michael has referred to as end-to-end data tests). I guess I must’ve created the openmrs-distro-oclqa with the intention of that being the test environment, so I think these tests either belong there or in the broader QA Framework (so this one test being the exception to the general rule).


Thanks @ibacher , i do think this can be achieved like

Create all the automated automated test in cypress following open concept lab instance. Then in the last feature file and step definition file, this is where we need to add a logic that will pick openmrs qa instance, Inotherwords, we shall be dealing with two instances at ago.

Then with in our tests, we need to call a URL for qa instance and do the other automation remaining, What am sure is, we wont separate them, implying using two instances at go, cc @ibacher how do you see my suggestion.

So, I think it’s important to bear in mind that these test are not tests of the Dictionary Manager itself nor are they centrally tests of the OCL API. They are tests of the functioning of the OCL module in an OpenMRS instance. This is different from both the existing testing that we already have for the Dictionary Manager (the Cypress tests) and the existing testing we already have for the OCL module (essentially some unit and integration tests).

So, the decision to spin up or connect to a QA instance is something that’s central to this; all of the tests will be communicating with the OpenMRS server. Frankly, we can even drop the requirement to make a new release on OCL.

The questions we want to answer through these tests are:

  1. When the module is setup to subscribe to OCL, can it connect to OCL and download the concepts?
  2. Are the concepts from OCL loaded into the OpenMRS concept dictionary correctly?

@sharif I think this somewhat revises how you outlined these tests working. Hopefully that’s clear enough?


This is an awesome question to think of, i think this is possible using subscription URL,

I tried to load a subscription URL and using token key though am seeing its returning some error URL though it shows the number of imported concepts.

Hi @sharif, would it be possible to share a screenshot of all errors and the link to the subscription URL that you’re using?

Hello @michaelbontyes , here is the screen shot

here is the link to the subscription URL

You probably need to release a new version. Unfortunately, exports aren’t as stably available on staging as they are on production, since it’s actively used for testing, etc.

Thanks @ibacher. It have worked

1 Like