Set Up Test Framework - efsity

[lincmba]

Superceded https://github.com/onaio/fhir-tooling/issues/20 FHIRCore Tooling currently lacks a proper testing framework. This is crucial for ensuring the stability, reliability, and quality of our tool, especially as we continue to develop and enhance its features. This will allow us to write and execute tests to validate the functionality of the tool and catch potential issues early in the development process.

Tasks

• [x] Identify the right testing frameworks for each of the modules in fhircore tooling (cleaner, efsity , importer , uploader)
• [x] Integrate the relevant testing framework to each of the project: JUnit for Java modules, Pytest for python modules
• [x] Write a set of initial test cases.
• [ ] Set up CircleCI to automatically run tests on code changes.
• [ ] Ensure all modules/directories mentioned above are covered in the CI tests
• [ ] Add documentation on testing
• [ ] Update the Engineer Checklist on the Pull Request Template to include CI passing

[pld]

I don't think we need the last todo item, if we're running CI it'll show it the PR automatically we don't need it in the templateOn Oct 31, 2023, at 07:41, Lincoln Simba @.***> wrote: FHIRCore Tooling currently lacks a proper testing framework. This is crucial for ensuring the stability, reliability, and quality of our tool, especially as we continue to develop and enhance its features. This will allow us to write and execute tests to validate the functionality of the tool and catch potential issues early in the development process. Tasks

Identify the right testing frameworks for each of the modules in fhircore tooling (cleaner, efsity , importer , uploader) Integrate the relevant testing framework to each of the project: JUnit for Java modules, Pytest for python modules Write a set of initial test cases. Set up CircleCI to automatically run tests on code changes. Ensure all modules/directories mentioned above are covered in the CI tests Add documentation on testing Update the Engineer Checklist on the Pull Request Template to include CI passing

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[lincmba]

After discussions with @ndegwamartin , This issue needs to be updated to reflect the following changes:

1. Use github actions for CI instead of Circle CI to be consistent with other fhir repositories.
2. This ticket should be split so that testing on each modules should be tracked individually. Then start with efsity module as a priority since it is the most active.

This ticket will therefore track setting up tests and testing framework for the efsity module, with the following tasks:

Tasks

• [x] Integrate JUnit testing framework to the efsity module.
• [x] Create tests folder and write a set of initial test cases.
• [x] Set up github actions CI to automatically run tests on code changes.
• [x] Add documentation on testing

Acceptance Criteria

• [x] TranslateCommand file Unit Tests written
• [x] Github Actions CI run the tests
• [x] Written tests passing on CI

[ndegwamartin]

I think we have a missing item we should have added here. That is adding Jacoco (Java Code Coverage) to the pipeline as well. This will help us get a coverage report once the test step runs.

Developers can run locally to view the report or we can hook it up to some online reporting tool like CodeCov or Coveralls.

This is a private repo so we may need an active subscription. This will be useful if we want to add a build check for a drop in coverage cc @pld

Alternatively we could see if we have some 3rd party open source approach options that don't require a platform like CodeCov e.g. explore this, this and this (or even build a solution ourselves that parses the locally generated report)

Resources

• https://www.jacoco.org/jacoco/
• https://about.codecov.io/
• https://coveralls.io/

[pld]

fine to cover subscription cost, I'd suggest we use codecov to be consistent with fhircore

[ndegwamartin]

Did some research, apparently it is possible to enforce some rules natively via Jacoco. Will try this out for the fhir-gateway-plugins repo. Doesn't entirely exclude the need for the coverage tools above though. cc @pld @lincmba

See article here : Enforcing Code Coverage rule with Jacoco in the Maven lifecycle

[ndegwamartin]

I explored the above and concluded that we should rather just use the CodeCov platform since the feedback the native set up provides doesn't give actionable feedback but rather just fails the build with a generic output. CodeCov would also get us some longitudinal tracking of the coverage .

Added the Jacoco integration for the fhir-gateway-plugins via the commit here cc @lincmba

For now it is possible to run the tests locally and view the html report of the covered (and uncovered) test classes for targeted testing. Once we set up the CodeCov subscription we can add the CI step to publish the report there.