added rs e2e test files and assertions for truncation logic

[GilmoreA6]

Add a PR title

Added two new files and relevant assertions to test leading zero truncation logic in RS e2e tests.

Issue

#1454

Checklist

• I have added tests to cover my changes
• I have added logging where useful (with appropriate log level)
• I have added JavaDocs where required
• I have updated the documentation accordingly

Note: You may remove items that are not applicable

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1454 - Partially compliant Fully compliant requirements: OBX-5 fields with NM data types will have leading zeroes truncated Assertions added to RS e2e tests that check leading zeroes are truncated appropriately Not compliant requirements: A sample ORU message sent by ReportStream staging to the UCSD receiver is filed successfully by their EHR test environment with all OBX-5 values preserved with the exception of leading zeros.

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Score
Possible bug	Correct the expected value in the assertion rule to match the actual HL7 message content Ensure that the rule for 'OBX-5' value in the 'CDPH leading zeros' assertion matches the actual value in the HL7 message. The current rule expects '5.100' but the HL7 message contains '05.100'. rs-e2e/src/main/resources/assertion_definitions.json [46] -"OBX-5 = '5.100'" +"OBX-5 = '05.100'" Suggestion importance[1-10]: 10 Why: The suggestion correctly identifies a mismatch between the expected value in the assertion rule and the actual value in the HL7 message, which is crucial for accurate data validation. Fixing this ensures the assertions will correctly validate the data as intended.	10

[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 SonarCloud

[halprin]

Looks kick-ass to me. @basiliskus, mind taking a look?

[basiliskus]

Looks good! It's a different approach in terms of setting the conditions to test but it completely makes sense to me for this kind of use case

[GilmoreA6]

Looks good! It's a different approach in terms of setting the conditions to test but it completely makes sense to me for this kind of use case

@basiliskus ya, I considered adding a new rule type that would check a regex and see if it matched and then we could apply it broadly but decided that could be a future enhancement and it made more sense to have specific test cases for right now