@@ -660,3 +660,126 @@ When building the frontend image for OpenMRS 3, the system automatically detects
660
660
- ` --progress=plain` : This option shows the build progress in plain text format, making it easier to track the build process. (this is optional)
661
661
- ` -f ./frontend/Dockerfile` : Specifies that we are using the frontend Dockerfile for building
662
662
- ` -t msfocg/openmrs3-frontend:qa` : tag of the frontend image must have the same name as in docker compose.
663
+
664
+ # [e2e Testing](#e2e-testing)
665
+
666
+ The MSF/OCG LIME is build with an E2E test suite using the [Playwright](https://playwright.dev)
667
+ framework.
668
+
669
+ # # Running tests locally
670
+
671
+ Below are the steps you need to test the current version of the MSF/OCG LIME server.
672
+
673
+ ` ` ` sh
674
+ docker compose up -d
675
+ ` ` `
676
+ Then, in a separate terminal, run:
677
+
678
+ ` ` ` sh
679
+ cd e2e \
680
+ yarn install \
681
+ cp example.env .env \
682
+ yarn test-e2e --headed
683
+ ` ` `
684
+ < ! -- markdown-link-check-disable-next-line -->
685
+ By default, the test suite will run against the local server at ` http://localhost` .
686
+ You can override this by exporting ` E2E_BASE_URL` environment variables beforehand:
687
+
688
+ For example to ** test the latest release of openmrs** set ` E2E_BASE_URL` to point to the ` o3.openmrs.org` instance like below
689
+
690
+ ` ` ` sh
691
+ # Ex: Set the server URL to o3:
692
+ export E2E_BASE_URL=https://o3.openmrs.org/openmrs
693
+
694
+ # Run all e2e tests:
695
+ yarn test-e2e --headed
696
+ ` ` `
697
+ To run a specific test by title:
698
+ ` ` ` sh
699
+ yarn test-e2e --headed -g " title of the test"
700
+ ` ` `
701
+ Check [this documentation](https://playwright.dev/docs/running-tests#command-line) for more running options.
702
+
703
+ It is also highly recommended to install the companion VS Code extension:
704
+ (https://playwright.dev/docs/getting-started-vscode)
705
+
706
+
707
+ # # Features Tested
708
+
709
+ - User login
710
+ - Patient Registration
711
+ - Patient Search
712
+
713
+ # # Writing New Tests
714
+
715
+ In general, it is recommended to read through the official [Playwright docs](https://playwright.dev/docs/intro)
716
+ before writing new test cases. The project uses the official Playwright test runner and,
717
+ generally, follows a very simple project structure:
718
+
719
+ ` ` `
720
+ e2e
721
+ | __ commands
722
+ | ^ Contains " commands" (simple reusable functions) that can be used in test cases/specs,
723
+ | e.g. generate a random patient.
724
+ | __ core
725
+ | ^ Contains code related to the test runner itself, e.g. setting up the custom fixtures.
726
+ | You probably need to touch this infrequently.
727
+ | __ fixtures
728
+ | ^ Contains fixtures (https://playwright.dev/docs/test-fixtures) which are used
729
+ | to run reusable setup/teardown tasks
730
+ | __ pages
731
+ | ^ Contains page object model classes for interacting with the frontend.
732
+ | See https://playwright.dev/docs/test-pom for details.
733
+ | __ specs
734
+ | ^ Contains the actual test cases/specs. New tests should be placed in this folder.
735
+ | __ support
736
+ ^ Contains support files that requires to run e2e tests, e.g. docker compose files.
737
+ ` ` `
738
+
739
+ When you want to write a new test case, start by creating a new spec in ` ./specs` .
740
+ Depending on what you want to achieve, you might want to create new fixtures and/or
741
+ page object models. To see examples, have a look at the existing code to see how these
742
+ different concepts play together.
743
+
744
+ # # Open reports from GitHub Actions
745
+
746
+ To download the report from the GitHub action plan, follow these steps:
747
+
748
+ 1. Go to the artifact section of the action/plan and locate the report file.
749
+ 2. Download the report file and unzip it using a tool of your choice.
750
+ 3. Open the index.html file in a web browser to view the report.
751
+
752
+ The report will show you a full summary of your tests, including information on which
753
+ tests passed, failed, were skipped, or were flaky. You can filter the report by browser
754
+ and explore the details of individual tests, including any errors or failures, video
755
+ recordings, and the steps involved in each test. Simply click on a test to view its details.
756
+
757
+ # # Debugging Tests
758
+
759
+ Refer to [this documentation](https://playwright.dev/docs/debug) on how to debug a test.
760
+
761
+ # # Configuration
762
+
763
+ This is very much underdeveloped/WIP. At the moment, there exists a (git-shared) ` .env`
764
+ file which can be used for configuring certain test attributes. This is most likely
765
+ about to change in the future. Stay tuned for updates!
766
+
767
+
768
+ # # Github Action integration
769
+ The e2e.yml workflow is made up of two jobs: one for running on pull requests (PRs) and
770
+ one for running on commits.
771
+
772
+ 1. When running on PRs, the workflow will start the OpenMRS msf server, and run tests only on chromium.
773
+ This is done in order to quickly provide feedback to the developer.
774
+ The tests are designed to generate their own data and clean up after themselves once they are finished.
775
+ In the future, we plan figure out how to run containers within a small amount of time.
776
+ 2. When running on commits, the workflow will spin up a docker container and run the msf server against
777
+ it in order to provide a known and isolated environment. In addition, tests will be run on multiple
778
+ browsers (chromium, firefox, and WebKit) to ensure compatibility.
779
+
780
+ # # Troubleshooting tips
781
+
782
+ On MacOS, you might run into the following error:
783
+ ` ` ` browserType.launch: Executable doesn' t exist at /Users/<user>/Library/Caches/ms-playwright/chromium-1015/chrome-mac/Chromium.app/Contents/MacOS/Chromium```
784
+ In order to fix this, you can attempt to force the browser reinstallation by running:
785
+ ```PLAYWRIGHT_BROWSERS_PATH=/Users/$USER/Library/Caches/ms-playwright npx playwright install```
0 commit comments