Bg/app 493/convert qa01 report

[brick-green]

Description

Checklist for adding a library:

• Copy this checklist into your (draft) PR description
• Check the existing description for the library in apps/modernization-api/src/main/resources/db/changelog/report/execution/03_ODSE_Data_Report_Library_Init.sql
  • If the report execution service is not yet in use by any STLT (even beta), you should update this file
  • Update the description in the library-specific migration
• Add a migration to apps/modernization-api/src/main/resources/db/report/execution/libraries named <your library name>.sql
  • Copy another migration and update the variables at the top of the file
• Add the migration to apps/modernization-api/src/main/resources/db/report-execution-changelog.yml. It should be added to the latest changeSet since the last release - this could require a new changeSet if there isn't one since last release
• Check the migration works by building/running the containerized dev setup
• Add a python library file to apps/report-execution/src/libraries named in lowercase, but generally following the naming convention of SAS (needs to be human recognizable as the same library)
• Follow the pattern established in existing libraries to create your library. The execute function is the required method and its signature will (someday) be checked for validity
  • Make sure pertinent text embedded in the reports is included in the description of the report
  • Note in the doc string any deviation from the SAS
• Keep an eye out for things in the sas library that are/could be centralized to pre- or post-processing or a util would be helpful for (e.g. common formatting needs)
• Add integration tests in a apps/report-execution/tests/libraries/<your_library_here>py file following the conventions established for other libraries
  • The subset_sql can be assumed to be well tested by the modernization-api, so focus on any logic and additional joins/queries/analysis that is added in the library
  • The database used in integration testing is our standard golden db + seed used in other testing - if additional data is needed to test the report, add it to the seeding process
• Add e2e test coverage for the report
  • If this step is not set up, create a ticket to track this as follow on work needed for this report
• Check that the report has parity with the NBS 6 version using (https://cdc-nbs.atlassian.net/wiki/spaces/NE/pages/2372272139/Comparison+Testing+Libraries)
• Keep an eye out for opportunities to:
  • Consolidate reports by using parameters (parameter design tbd)
  • Improve the report spec or result expectations
• Update the SAS to Python tracking spreadsheet with information about the newly converted library
• Update/clarify these instructions in the epic based on your experience

Tickets

• Jira Ticket

Checklist before requesting a review

• PR focuses on a single story
• Code has been fully tested to meet acceptance criteria
• PR is reasonably small and reviewable (Generally less than 10 files and 500 changed lines)
• All new functions/classes/components reasonably small
• Functions/classes/components focused on one responsibility
• Code easy to understand and modify (clarity over concise/clever)
• PRs containing TypeScript follow the Do's and Don'ts
• PR does not contain hardcoded values (Uses constants)
• All code is covered by unit or feature tests

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud