GSoC 2023: An effective unit & integration test strategy for OpenMRS3
Introduction
OpenMRS consists of several micro frontend modules and repositories, most of which have unit and integration tests written by individual developers. However, these tests exhibit inconsistencies due to the diverse testing strategies used by different developers. To address this issue, there is a need for a consistent and comprehensive test strategy or framework for the unit and integration tests of OpenMRS3, aimed at achieving a high level of test coverage.
Objectives:
Implementing an effective unit & integration test strategy for OpenMRS3.
Expectations:
Develop a comprehensive testing strategy that can be applied to all OpenMRS3 micro frontends.
Determine what to test (e.g. In react → props, state, rendering, event handling, error handling)
Ensure test coverage (e.g. edge cases, positive and negative scenarios)
Document the strategy
Outline the necessary tests based on the strategy (including a draft for a single repository in the project proposal)
Upgrade existing tests to align with the new strategy
Implement any missing tests
Resolve any bugs in the current tests.
Further improvements (Optional):
Improve the code quality testing mechanism (ex: eslint)
Project Size:
Medium
Skills required:
Familiarity with OpenMRS microfrontends (including setup and directory structure)
Background in microfrontend development
Proficiency in testing techniques
Final Outcome:
A robust, well-documented unit and integration testing strategy for OpenMRS3 microfrontends
To be used as a reference by developers in future development efforts.
I raised a PR adding patient-flags into RefApp 3.x as an initial task for the ANC prototype but merging is blocked for now because the backend module is not-worthy.
As a matter of fact, I personally had to do some tweaks with this module for successful getting of the flags from the backend.
@jnsereko Thanks for this work. We’re going to hold off on merging this for right now not because the frontend part is in any way not what is called for in the designs, but because I think the backend module needs to be re-engineered before it’s ready to be integrated into the RefApp. In particular, I want to be sure that it performs well enough. Once we have that added to the RefApp, we can merge this PR in.
(PS Validating and re-working the backend module for this would be an excellent GSoC project…)
I have come up with some improvements for the O3 form builder that I believe could enhance its functionality. These include
Reference forms
Ability to edit answers (Same as Ampath)
Ability to edit concept mappings (Same as in Ampath)
Ability to rearrange questions (This was suggested by Grace, where the user can rearrange the questions by dragging)
However, these improvements may not be sufficient for a 175-hour project, and I am open to any suggestions for further enhancements.
As I will be on vacation this summer, I’m interested in mentoring a GSoC project this year, if possible.
I am particularly interested in the following projects
Thanks for your interest in becoming a mentor @kumuditha!
@dennis, do you have any suggestions on how to turn the form builder into a GSoC project?
Alternatively, do you have a specific project in mind that Kumuditha could mentor?
I looked into O3: Draw on Body Diagram project idea and I think if we can scope it down to mark certain areas of an upload diagram – either with a certain shape, or a single point – and provide support to it with a data structure that can facilitate those meta data we’ll have a well scoped idea for medium sized project. Storing an array of x, y coordinates with the description will be a simple way of achieving this goal, This way we will be able make nice looking and interactive diagrams. There could be different ways like storing them within the digram itself through vector files too. We can put the dynamic drawing as an optional objective of the project and extend the basic implementation to include them later on.
I think a good proposal for this project should include,
A good requirement analysis
A good explanation on how to handle different image types
Good data structure design to store diagram meta data
Plans on,
How to handle the diagram upload and store
How to handle the editing of the diagram on the frontend
How to render those diagrams properly with the edits
Set of wireframes for the UIs
The list of API endpoints that is needed to support those UIs
Even though I won’t be able to write proposal myself since I’m working as a full time SE, I’m very much interested in getting involved in this project to help out whoever that wants to submit a proposal for this idea or even mentor the project if needed.
I’m also interested in 03: Responsiveness & Tablet-based Needs for OpenMRS 3 project. The main objective of this project is to make the responsiveness of the application consistent throughout devices. Since OpenMRS 3 is developed on Tablet first, I couldn’t be able to find many issues on the tablet view in the patient chart. But we can improve the responsiveness in other modules in the application such as Fast Data Entry, Corhort builder and Form builder.
Optimizing the code for better performance. Remove unused code, and optimize loops and conditions.
Test the application on different devices with different screen sizes, and resolutions to ensure the interface is responsive and functions properly on all devices. This will help us to identify more bugs in the interface.
Here are a few things that I think a good proposal should contain.
Requirement gathering (Identifying bugs/issues)
Identified issues in Tablet-based screens
Identified issues in Laptop screens
Implementation plan for
Tab based responsiveness
Laptop based responsiveness
Wireframes depicting the designs
Skills
React
Typescript
Javascript
What do you folks think?
I would love to help make it a success by offering my assistance as a mentor or in any other way. Please let me know how I can be of help, as I am enthusiastic about contributing to this project in any way possible.
Hey @kumuditha !
Interesting capture of the project needs and requirements. Just want to clarify, are you interested to contribute as a developer contributor or as a mentor?
Hi @dennis I am much interesting in workin gon this project.
In simple terms the project requires migrating the forms from vanella react to reack hooks which enhance better functionality.
Can I create a project topic on the openmrs so we discuss the idea more there or which other way is the best.
My name is Akshat, and I’m interested in participating in Google Summer of Code (GSoC) 2023. I’ve been exploring project ideas on the GSoC website, and I’m particularly interested in your project on " Migrate forms to React Hook Form for OpenMRS 3" .
I’m writing to you to request your guidance on this project and to learn more about your expectations for potential contributors. I’m keen to understand the scope of the project and any resources or materials I should review before getting started.
Finally, I would appreciate it if you could share your email address so that I can connect with you further and keep you updated on my progress.
Thank you for your time and consideration. I look forward to hearing back from you soon.
Technically, it’s more trying to migrate from one form library (Formik,) to another (RHF) while trying to maintain the benefits of using a React-focused form library (minimise unnecessary component re-renders, work with React’s onChange weirdness, validation integration, etc.).
Hi all, This is regarding the project idea I suggested above. I updated this document by including my findings on O3 Unit and Integration Tests. Here is a summary:
These are some of my findings:
The unit/integration test coverage is low. (Some O3 modules have no tests at all)
We have been mocking the openmrsFetch function to mock the network calls in existing tests. We can replace it with MSW(Mock service worker) which is a better way of mocking the network calls.
Major suggestions which I made are:
Rewrite the existing integration tests to work with MSW (Mock service worker)
Improve the Unit and Integration test coverage
By Writing the missing tests
By Improving the existing tests
If we can add a GSoC project on this, the selected student can work on fulfilling the main requirements (suggestions) mentioned above.
At the end of the project, the OpenMRS3 modules will have a comprehensive set of unit and integration tests for the existing features. It will enable O3 developers to refer to them when developing new features in the future. It will also help us to move towards test-driven development, which is one of the goals of the QA squad.
O3: Validating and re-working (update and upgrade) 