-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create Test Harness For End To End Testing #70
Comments
@dixonwhitmire very interested in seeing the outcome of this if it goes ahead as I'm involved with internal IBM teams using HL7, FHIR, Linux 4 Health from a Quality / Test perspective. I'd offer to help for the Hackathon but I'm already involved with another team. Also I know you guys are Java and I'm almost exclusively Python. I do think that Python would offer some easy wins with it's json / str / hl7 handling capabilities and it's PyTest infrastructure. Even so this is something I'm interested in seeing presented in a couple of week. Feel free to ping me directly if you think that there is anything that I can do to help. |
This was discussed in our hackathon mtg on 3/30 -- we (Clinical Data Pipeline) have a card we are working on that is creating a testing mechanism very similar to this: https://github.ibm.com/wh-imaging/cdp-dataenrichment/issues/33 |
Hey @DavidColton-IBM thanks for reaching out! We are currently working on a python based component in the LFH stack that's using Fast API, pytest, Pydantic, etc. This component isn't "public" yet but will be ready in a few weeks. I'll set up some time so that we can chat about this offline. Thanks! |
This issue enhances the converter's existing test case suite with a test harness we can use to run an end to end test. An "end to end" test is simply a test that validates the FHIR Resource output for a given HL7 message template.
To support this type of test we will need to add a "test harness" which does the following:
The test harness could be a parameterized Java method or a JUnit5 parameterized test case. We may not be able to do a simple comparison of JSON objects for the actual and expected resources as we don't have field ordering guarantees and some generated fields such as
uuid
will be unique across test case runs. Using a Comparator or similar sorting mechanism could help here.The text was updated successfully, but these errors were encountered: