Skip to content
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

Test case "Bad profile" for DocumentRecipient comprehensive test collection #228

Closed
aschnab opened this issue Mar 27, 2024 · 5 comments
Closed
Assignees
Labels
bug Something isn't working
Milestone

Comments

@aschnab
Copy link

aschnab commented Mar 27, 2024

Hi,

I have been been using the FHIR Toolkit to test my implementation of an MHD Document Recipient/Document Responder, and I have noticed a strange test test result for the "Bad Profile" test case in the "MHDv410 DocumentRecipient comprehensive" test collection.

The test sends an ITI-65 request containing the erroneous Bundle profile declaration "http://ihe.net/fhir/StructureDefinition/IHE_MHD", and, by its decription, expects the MHD server to respond with an HTTP 400 response (which my MHD server does). Looking into the test's script, I can see that it expects the following set of assertions to fail (expectedFailAssertionIdList): 'RM410_4'|'CMPDR_3_1'|'TR_1'.

However, the test as a whole fails for me. Inspecting the details of the test results, I can see the test failure resulting from the step "PDB Validations." Here, the following three substeps are marked as failing:

  1. "PDB Validations - Request message." - here, the assertion "Bundle.meta.profile: Minimal Metadata or Comprehensive Metadata." (Assertion ID: RM410_4) fails. Since this assertion's ID is contained in the above expectedFailAssertionIdList, I suppose that this assertion failure is expected and should not cause the test as a whole to fail.
  2. "If Comprehensive Metadata." - here, the assertion "Transaction must be labeled Comprehensive Metadata." (Assertion ID: CMPMETA_3) fails. This assertion's ID is NOT contained in the above expectedFailAssertionIdList, so I suppose that this point is what causes the test as a whole to fail - correct?
  3. "Transaction response." - here, the assertion "Transaction: http 200 response." (Assertion ID: TR_1) fails. Since this assertion's ID is contained in the above expectedFailAssertionIdList (and, going by the test's description, this assertion's failure should be a main point of this test), I suppose that this assertion failure is expected and should not cause the test as a whole to fail.

So, by the looks of it, the second of the three above mentioned assertion failures is causing the test to fail here. However, the test's setup description ("Bundle.meta.profile contains an invalid value") is in direct contradiction to what this assertion checks for (and neither is it even in the DocumentRecipient's power to change this profile declaration on the request side).

Am I correct in my conclusion that the above described test failure is just due to the setup of this specific test in the toolkit, and not indicative of any deficiencies in the system under test?

@skbhaskarla
Copy link
Collaborator

Correct.
Also affected by the same problem is the Missing Profile test.
Please see the commit 82a768c on a separate branch with the fixes. Thanks

@skbhaskarla
Copy link
Collaborator

In future, please post to the IHE MHD group first so that others might take notice of the problem as well.

@skbhaskarla skbhaskarla self-assigned this Mar 27, 2024
@skbhaskarla skbhaskarla added this to the V4.3.0 milestone Mar 27, 2024
@skbhaskarla skbhaskarla added the bug Something isn't working label Mar 27, 2024
@aschnab
Copy link
Author

aschnab commented Mar 28, 2024

Thanks! The tests are running fine on my setup now (interestingly, the "Missing Profile" test case was working fine for me even before the fix, though).

In future, please post to the IHE MHD group first so that others might take notice of the problem as well.

Will do.

Regards, Andreas

@skbhaskarla
Copy link
Collaborator

Let me fully explain this bug fix and why the Missing Profile appeared to have passed on your side.

The Bad Profile negative test (and the Missing Profile test) originally had incorrect comprehensive DocumentReference metadata, it was missing the DocumentReference content attachment creation element. When you had reported the issue, only the Bad Profile had correct metadata but incorrect expected assertion fail Id, but the Missing Profile test had both incorrect metadata and incorrect expected assertion Id. You can see this in the referenced commit 82a768c.

As a requirement to Comprehensive DocumentReference metadata,

XDS DocumentEntry creationTime is required in the Optionality Table:
https://profiles.ihe.net/ITI/TF/Volume3/ch-4.3.html#4.3.1

FHIR mapping:
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Comprehensive.DocumentReference-mappings.html#mappings-for-xds-and-mhd-mapping-xds

The Toolkit tests incorrectly set the expected assertion fail to CMPDR_3_1 which was missing creation

"CMPDR_3_1": [{"mhdComprehensive": "DocumentReference", "context": ".content.attachment.creation"},

When you had run the Missing Profile test, the (incorrect) assertion test subject failed, and test passed (incorrect). This is what appeared to have happened with your Missing Profile test result.

Once the required creation element was fixed in test metadata through this bug fix, the correct error was triggered at CMPMETA_3.

"CMPMETA_3": [{"mhdv4": "ITI-65_BundleResources", "context":"Bundle.meta.profile",

Sorry for the confusion.

@aschnab
Copy link
Author

aschnab commented Apr 2, 2024

Ah, now I see: the Missing Profile test was testing something different than advertised, but it was doing so consistently. Thanks for the explanation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants