Skip to content

Latest commit

 

History

History
145 lines (104 loc) · 7.43 KB

README.md

File metadata and controls

145 lines (104 loc) · 7.43 KB
Raw

CARE Logo

Our goal is to continuously improve the quality and accessibility of public healthcare services using digital tools.

🚀 Staging Deploy

Auto deployed to care.ohc.network for develop branch. All pull requests have preview builds powered by Netlify.

Quality Gate Status Code scanning - action OSSAR Cypress Tests Staging Release Production Release Codacy Badge CircleCI Maintainability

Getting started

  • 💬 Comment on the issue if you are willing to take it up, and link the pull request with the issue.
  • 🏷️ Tag @ohcnetwork/care-fe-code-reviewers for faster resolution.
  • 📸 Attach screenshots in the pull requests showing the changes made in the UI.

Install the required dependencies

npm install

Run the following command to generate the supportedBrowsers.ts file:

npm run supported-browsers

This script just generates regex expression for matching the list of compatible browsers, so that we can show a warning notification for unsupported browsers.

🏃 Run the app in development mode

npm run dev

Once the development server has started, open localhost:4000 in your browser. The page will be automatically reloaded when you make edits and save. You will also see any lint errors in the console.

🔑 Staging API Credentials

Authenticate to staging API with any of the following credentials

- username: dev-districtadmin
  password: Coronasafe@123
  role: District Admin

- username: staffdev
  password: Coronasafe@123
  role: Nurse

- username: doctordev
  password: Coronasafe@123
  role: Doctor

Contributing to CARE

  • Create a branch with branch name of the format issues/{issue#}/{short-name} (example issues/7001/edit-prescriptions) from the latest develop branch when starting to work on an issue.
  • Once the changes are pushed to the branch, make a pull request with a meaningful title (example: "💊 Adds support for editing prescriptions" #6369)
  • Ensure the issue number is mentioned in the PR with a closing tag by following the PR body template. (Refer: Linking a pull request to an issue)
  • Once the code review is done, the PR will be marked with a "Needs Testing" label where it'll be queued for QA testing.
  • Once tested, the PR would be marked with a "Tested" label and would be queued for merge.

Testing

To ensure the quality of our pull requests, we use a variety of tools:

  • Automated E2E Testing: We use Cypress for end-to-end testing to automatically verify the functionality and performance of our code.
  • Manual Real Device Testing: We use BrowserStack to manually test our code on real devices, ensuring compatibility and functionality across different platforms and browsers.

🧪 Run cypress tests

To run cypress tests locally, you'll need to setup the backend to run locally and load dummy data required for cypress to the database. See docs.

Once backend is running locally, you'll have to ensure your local front-end is connected to local backend, by setting the REACT_CARE_API_URL env.

#.env
REACT_CARE_API_URL=http://127.0.0.1:9000

Once done, start the development server by running

npm run dev

Once development server is running, then run the cypress tests in either of the ways described below.

npm run cypress:run        # To run all tests in headless mode.
npm run cypress:run:gui    # To run all tests in headed mode.
npm run cypress:open       # To debug and run tests individually.
  • Failed test screenshots are saved in cypress/screenshots
  • All test videos are saved in cypress/videos

📖 Documentations

🚀 Production

Build the app for production

npm run build

Builds the app for production to the build folder. It correctly bundles React in production mode and optimizes the build for the best performance.

Start a production http-server

npm run preview

Starts a production http-server in local to run the project with Service worker. The build is minified and the filenames include the hashes.

🚀 Your app is ready to be deployed!