Create integration test for the FHIR converter

[emmastephenson]

PULL REQUEST

Summary

Add a new integration test for the FHIR converter, and update our test workflows to ensure integration tests run on CI.

Related Issue

Fixes #438

Additional Information

This integration test uses a library called testcontainers, which has a bunch of different options, but the one we care about is the docker-compose module. This lets you spin up a docker-compose script inside a test, which you can then hit with requests. This does appear to cache the container between runs, at least locally, so the first test takes a while but they get faster subsequently assuming you don't change the container.

There's also some fun tricks happening with pytest here. One is marking the tests so they don't need to be executed per run, and the other is the setup/teardown aspect. They're currently configured to set up once, at the beginning of the test suite, and tear down only after all the tests have executed.

Finally, there's a new step of the testing process - integration-test-python-containers. A fun quirk of the way we run pytest is that if there are no tests found, the Github check fails. The way I'm getting around this is to specify that integration tests need to be in an integration folder.

For local testing - if you just run pytest everything will execute. If you run pytest -m "not integration" integration tests won't run; if you run pytest -m "integration" only integration tests will execute. (Will put this info in the wiki)

Background

• This PR was originally included in Add RR extraction logic, phdi dependency to FHIR converter #814; I split them to make reviewing simpler. The commit diff there unfortunately stinks, so I recommend reviewing Add RR extraction logic, phdi dependency to FHIR converter #814 first (I'll merge it first too)

[emmastephenson]

On all these integration tests, I'm not doing anything except verifying that the status is 200 and that there's a bundle in the body. I had originally hoped to create golden files for these tests and just assert response == golden, but each of the IDs in the bundle will be different on each run :/ Might be something to solve with the FHIR resource library.

[BradySkylight]

We should have 'golden' files for the ECR conversions already. I think this will be sufficient for now.

[DanPaseltiner]

Really exciting to see us finally implementing this kind of testing! 🚀

[BradySkylight]

This is awesome! We do have the before and after for Eicr conversion though. Both the RR and the EICR and the EICR with the RR added in, as well as the expected converted JSON file. This way you can test both steps the rr extraction and input into eicr as well as the full conversion.

[emmastephenson]

This is awesome! We do have the before and after for Eicr conversion though. Both the RR and the EICR and the EICR with the RR added in, as well as the expected converted JSON file. This way you can test both steps the rr extraction and input into eicr as well as the full conversion.

@BradySkylight yeah, I was really hoping to make this approach work - my original plan was to use the original EICR/RR files and the expected conversions as the goldens and just verify that the response matched. Unfortunately, the FHIR conversion doesn't generate consistent outputs each time - the Patient ID and timestamps change across each execution, so the comparisons always fail. I'm hoping there's some kind of pytest tooling that allows you to ignore certain variables in a golden, but I think that might be better suited for a followup PR.

[BradySkylight]

This is awesome! We do have the before and after for Eicr conversion though. Both the RR and the EICR and the EICR with the RR added in, as well as the expected converted JSON file. This way you can test both steps the rr extraction and input into eicr as well as the full conversion.

@BradySkylight yeah, I was really hoping to make this approach work - my original plan was to use the original EICR/RR files and the expected conversions as the goldens and just verify that the response matched. Unfortunately, the FHIR conversion doesn't generate consistent outputs each time - the Patient ID and timestamps change across each execution, so the comparisons always fail. I'm hoping there's some kind of pytest tooling that allows you to ignore certain variables in a golden, but I think that might be better suited for a followup PR.

That is strange. I may need to look into that...perhaps because it's making a UUID each time? Once I get this MPI stuff worked out, maybe we can look into this together.

[emmastephenson]

This is awesome! We do have the before and after for Eicr conversion though. Both the RR and the EICR and the EICR with the RR added in, as well as the expected converted JSON file. This way you can test both steps the rr extraction and input into eicr as well as the full conversion.

@BradySkylight yeah, I was really hoping to make this approach work - my original plan was to use the original EICR/RR files and the expected conversions as the goldens and just verify that the response matched. Unfortunately, the FHIR conversion doesn't generate consistent outputs each time - the Patient ID and timestamps change across each execution, so the comparisons always fail. I'm hoping there's some kind of pytest tooling that allows you to ignore certain variables in a golden, but I think that might be better suited for a followup PR.

That is strange. I may need to look into that...perhaps because it's making a UUID each time? Once I get this MPI stuff worked out, maybe we can look into this together.

@BradySkylight yeah, I think it is the Patient UUID in particular making it non-idempotent. Would be happy to look at it with you later!