Seeking Guidance on Testing Version-Specific REST Resources (Concept Reference Range)

Development
1

Hey everybody, I’m working on re-implementing the /conceptreferencerange endpoint for platforms < 2.7 (originally from PR #654, removed in #670). Ticket here.

Approach:

  • For 2.5-2.6: Using ConceptNumeric as the delegate class (no ConceptReferenceRange API available). Returns static reference range values from the ConceptNumeric itself. isCriteriaBased = false since ranges aren’t patient-specific.
  • For 2.7+: Uses ConceptReferenceRange with criteria-based patient-specific lookup. isCriteriaBased = true.

The resource implementation is straightforward, but I’m unsure about the testing approach. Since the test environment uses OpenMRS 2.8.3, the 2.7 resource gets loaded instead of the 2.5 resource, causing controller tests to fail. What’s the recommended approach for testing version-specific resources in the current consolidated codebase? Should we:

  1. Use resource-level tests only (directly instantiating the resource)
  2. Re-introduce version-specific modules like the original PR #654
  3. Use Maven profiles to switch OpenMRS test versions
  4. Something else?

For context, this is blocking a related PR that requires the endpoint for < 2.7:: (feat) O3-5307: Use criteria-based reference ranges in lab results display by UjjawalPrabhat · Pull Request #2928 · openmrs/openmrs-esm-patient-chart · GitHub

Thanks!

2

Because the current master branch of the module does not support those openmrs versions, you would need to use the 2.x branch.

1 Like