Patient registration: Unexpected behaviour in E2E test

When I’m fixing some failing E2E tests by this PR, I noticed a strange behaviour in the patient registration. I’ve attached some screen recordings. Before going into that, let me first explain how the registration test is designed. The test contains two scenarios:

  • Scenario 1: Fill the form with the correct values and expect the message “New Patient Created”
  • Scenario 2: Fill the form with some missing values and expect the message “Incomplete form”

If a scenario is failed it will retry two times until it gets passed. It was configured because sometimes tests fail as it takes more than 40 seconds to load the page. The following screen records are produced by cypress when running tests on GitHub actions.

  1. patient-registration.feature 6.mp4 - Google Drive
  2. patient-registration.feature 7.mp4 - Google Drive

If you go through the video, you can identify following the following. Please note that I couldn’t any of these issues when testing it manually. It happens only when running with cypress. The chances of failing are very high on CI and low when running cypress on my local setup.

  • The “Register Patient” Button is disabled from the beginning.
    • You can see the button is disabled most of the time. Cypress fills the form and waits to click on the button, but it fails after the 40-second timeout because the button isn’t in a clickable state.
  • Inputs are being cleared while filling out the form
    • You can see some inputs are being reset while filling out the form

Possible reasons for the above issues are as follows:

  • An issue with Cypress

    I think it’s highly unlikely in the given situation because we can see it’s trying to perform what we have expected.

  • An issue with the UI

    It might be an issue with the way we have implemented the patient registration.

  • Performance of the machine

    Since we are using a Github-hosted runner to spin up the docker container and run tests it might affect the performance of the application. (Maybe the UI isn’t completely loaded while we performing actions even though it seems loaded?) However, it fails on my local setup sometimes as well (I have a 16GB M1).

I thought of sharing this because it might help us to stabilise E2E tests as well as to track down if there are any performance issues with the application. Please let me know your input.

Passing run: O3-1655: Fix existing tests · openmrs/openmrs-test-3refapp@e9a1d6d · GitHub

Failing run: O3-1655: Fix existing tests · openmrs/openmrs-test-3refapp@a27bd1a · GitHub

cc: @dennis @grace @ibacher @raff

I went through the implementation and figured out the button is disabled until the current session and identifier types are loaded.

Therefore I updated the test to wait until the button is enabled before filling out the form. Now the test is passing. O3-1655: Fix existing tests · openmrs/openmrs-test-3refapp@0031303 · GitHub

It opens up a new question, why it is taking such a long time?

1 Like

Here’s another issue; The modal doesn’t render properly when trying to end a visit. It’s somewhat hard to reproduce.

Video: https://drive.google.com/file/d/1q4K4eTCh4k90wr7vLAANNSAbLWmuuA00/view?usp=share_link

Failing run: O3-1655: Fix existing tests · openmrs/openmrs-test-3refapp@0031303 · GitHub

Ooo that’s an interesting one. @hadijah315 or @vasharma05 have you ever run into this?

My first gut response is, could there be something in the responsiveness framework causing this? CC/FYI @dkigen

@jayasanka how did you reproduce this? I skimmed the video but that one is for registration, I didn’t see the end visit (maybe I need to rewatch)

Sorry, here’s the updated link:

This issue occurred on the last PR I sent: O3-1655: Fix existing tests · openmrs/openmrs-test-3refapp@0031303 · GitHub

PS: I was able to reproduce this locally by running the e2e test on my machine.

There are three elements rendered within the modal.

I did a small investigation :grin:

The issue was with the way the test is written. The {force: true} option has been used for button clicks which leads to unexpected behaviours.

Explanation: Part 1: Loom Message - 24 November 2022 - Watch Video

Part 2: Loom | Free Screen & Video Recording Software | Loom

2 Likes

It opens up a new question, why it is taking such a long time?

@jayasanka , actually the fetching of patient identifiers makes subsequent calls to the backend. The requests are chained and hence it takes some time to load and hence it takes that much time.

Regarding the ending visit modal issue, can you share a suitable time for a meet where we can have a look at it together, since this behaviour is not coming up on the UI flow. I and @hadijah315 will be happy to help you out. Thanks!

Thanks for the reply @vasharma05 ! :hugs: It was an issue with the way we have written the test. It clicked on the “End Visit” menu item instead of the red colour button on the modal. Which resulting another element to the modals container. I fixed the test and it is working fine now.

Key takeaways:

  1. We need to pay extra attention when using selectors to pick elements in tests.
  2. It would be a lot easier if we have e2e tests within relevant repositories. So that we can add identifiers for elements if needed and purpose changes with the same PR.
1 Like