Patient registration: Unexpected behaviour in E2E test

jayasanka · November 23, 2022, 1:17pm

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.

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: @dkigen @grace @ibacher @raff

jayasanka · November 23, 2022, 1:50pm

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

github.com

openmrs/openmrs-esm-patient-management/blob/b187a826b6c71748ce008ce853b59f872b97fc8b/packages/esm-patient-registration-app/src/patient-registration/patient-registration.component.tsx#L202


      
                <div className={`${styles.space05} ${styles.touchTarget}`} key={section.name}>
                  <Link className={styles.linkName} onClick={() => scrollIntoView(section.id)}>
                    <XAxis size={16} /> {section.name}
                  </Link>
                </div>
              ))}
              <Button
                className={styles.submitButton}
                type="submit"
                onClick={() => props.validateForm().then((errors) => displayErrors(errors))}
                // Current session and identifiers are required for patient registration.
                // If currentSession or identifierTypes are not available, then the
                // user should be blocked to register the patient.
                disabled={!currentSession || !identifierTypes}>
                {inEditMode ? t('updatePatient', 'Update Patient') : t('registerPatient', 'Register Patient')}
              </Button>
              <Button className={styles.cancelButton} kind="tertiary" onClick={cancelRegistration}>
                {t('cancel', 'Cancel')}
              </Button>
            </div>
          </div>

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?

jayasanka · November 23, 2022, 1:58pm

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

grace · November 24, 2022, 12:41am

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)

jayasanka · November 24, 2022, 5:33am

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.

jayasanka · November 24, 2022, 9:04am

I did a small investigation

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

vasharma05 · November 25, 2022, 7:09am

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!

jayasanka · November 25, 2022, 9:18am

Thanks for the reply @vasharma05 ! 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:

We need to pay extra attention when using selectors to pick elements in tests.
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.