Reference Application 2.13.0-SNAPSHOT Testing

Are you interested in running automated tests for Reference Application 2.13.0-SNAPSHOT locally? Kindly follow these steps:

  1. clone the repository → GitHub - openmrs/openmrs-contrib-qaframework.

  2. cd into the repository using → cd openmrs-contrib-qaframework

  3. Import the project in your preferred IDE and change the file to something like this:


and save the changes.

  1. Navigate to the qaframework-bdd-tests module using → cd qaframework-bdd-tests.
  2. Trigger npm run in the terminal in order to see all the workflows that have been created
  3. Trigger any test workflow by running the command: → npm run workflowName, e.g. npm run refapp2ClinicalVisit

Kindly report you findings on this link Reference Application 2.13.0-SNAPSHOT Testing - Google Sheets

cc@jayasanka, @piumal1999, @MekomSolutions, @PIH, @mherman22 , @ugandaemr, @kdaud, @AMPATH, @tendomart, @devnull, @dev1, @dev2, @dev3, @dev4, @dev5


Hello friends, I know testing this release has not been a walk in the park but nevertheless, I want to say thank you for the spirit and patience. Since the tests were flopping on the github action, we opted to run automated tests locally in the feature file linked to every workflow and spinned the tests against the which is running Reference Application 2.13.0-SNAPSHOT and this is our findings. As communicated prior we anticipate the release to come-out anytime from now not unless we face any constrain beyond our control. Thanks!

It’s a bit strange to see only 25% of the automated tests passing in github actions when running with the uat server for RefApp 2.13.0-SNAPSHOT. The rest of the tests are throwing a general server failure(HTTP 404 not found), I am not able to figure out the real cause of the issue but this could be something worth considering before releasing the refapp.

@ibacher @dkayiwa what could be your advise?

@kdaud are you able to reproduce any of those errors, on uat-refapp, when you manually do what the tests are automating?

The manual attempt could not reproduce any of those errors. Taking further investigation on github actions have been able to figure out the reason why the tests were failing before and made commits (a8cd9eb, a6665d8) that made the tests pass. Though there remains only two tests failing which am investigating but I realize enabling the includes.csrftoken functionality makes all the tests fail login step probably because the functionality was introduced in platform 2.6.0 and the uat is using 2.5.9.

Unable to locate element: *[name='OWASP-CSRFTOKEN']

I may not tell why we are not using the recent released platform version, @jwnasambu could you help me understand the pitfall that were occurring when using the new version which led to this downgrade?

FYI, the qa-refapp server is also running on 2.5.9 as can be seen at and the tests seem to be passing on the qa-refapp server.

@dkayiwa we now have all the tests passing in github actions running against uat server when includes.csrftoken is disabled otherwise they all fail with the error I shared above. Is it worth looking for the workaround to have the tests pass when the property is enabled or @jwnasambu can proceed with releasing the refapp 2.13.0?

includes.csrftoken should be enabled for only platform 2.6.0 and above.

This makes sense! @jwnasambu you should be good to go →

@dkayiwa, something confusing is that we are running the tests in github actions against a local host instance configured in a dockerized environment. The local host uses an updated qa image, the platform version is 2.5.9, includes.csrftoken is enabled and all the tests are happily running. Could you help me understand what is happening here?

@kdaud kindly am looking at the logs on the github action under Run qaframework on selenium and am getting this {"error":"Could not process your messages because of the following error(s): \n- project-access-token: can't be blank"} Does this error matter or not? It’s the massage appearing on every workflow.

Enabling it for lower versions of the platform is harmless and should not lead to any test failure.

Thanks @dkayiwa for the precise and clear answer, next time will help someone else understand it :grinning:

Could you share the url to those logs?

This is for Roles and Privileges workflow Switch server · openmrs/openmrs-contrib-qaframework@c937644 · GitHub

Do you mind pointing out the line number where the log is happening ?

Switch server · openmrs/openmrs-contrib-qaframework@c937644 · GitHub line 12993

The answer is no, and should be ignored.

Those logs are pointing out the expiry of project-access-token: ${{secrets.CUCUMBER_IO_TOKEN}} and requires updating the token. All the workflows are configured to process a build plan message at the end of the test run, the message is published on cucumber reports and this setting resides in every workflow, you may take a look at one → here

Thanks for the clear explanation @kdaud . All the tests are passing both locally and on github action. Should I wait for the ticket to be merged for me to proceed with the next release step?

cc @dkayiwa, @ibacher

1 Like

I don’t think since we were testing out our new baby refapp with the automated tests and has proven worth after the tests running through her major functionalities/user workflows.

My recommendation would be for you moving to the next release step however, @dkayiwa’s advise at this step should be considered before you move on to the next stage.

1 Like

Thanks so so much for everything. I’m really grateful for your help.