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

2 Likes

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.

2 Likes

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