Practical Application

Code Analysis

• Linting: We use ESlint
• Typechecking: We use Typescript
• Results are should shown to devs at time of PR, for fast feedback turn around times.

Unit Tests

• Unit Test Runner we use in 3.x: Jest
• Good example of Unit Test coverage: https://github.com/openmrs/openmrs-esm-core/tree/master/packages/apps/esm-login-app
• To see other examples, you can explore see the patient chart apps here: https://github.com/openmrs/openmrs-esm-patient-chart/tree/master/packages 

Regression Testing

• IN PROGRESS: Bug Policy: When you fix a bug, the fix should generally be accompanied by a test for that problem to prevent that same problem in the future.
  • When a regression cannot be unit tested, an E2E test case should be provided instead. (Product team discretion advised.)

Performance

• Load times: 
• Load testing & scope of load tested: 
• Relevant Epics in-progress: 
  • O3-769 - Getting issue details... STATUS
  • O3-912 - Getting issue details... STATUS
  • O3-1162 - Getting issue details... STATUS

Build & CI Tooling

• Frequency of build status checks: Done weekly at minimum; also part of OpenMRS QA Dashboard here
• 3.x Distro Build in Bamboo CI: here
• TODO: Monitoring Solution / Automated Site Smoke Tests

Integration Tests

• TODO:  Mock Integration Tests
  • Run sample E2E tests against each PR without needing a whole new distro re-built. 
  • Next step: Build a framework for doing this, and build it into esm-patient-chart as a starting place - establish the patient chart integration tests. Something that, once set up, can be maintained by everybody. 

E2E Tests

• Our current E2E tests use the actual server. Currently working to dockerize these. 
• Dashboard and inventory of Cypress&Cucumber-based BDD tests: here
• Overview of E2E Tests' Workflow content: here