This document describes the testsuite for GetLaboratoryOrderOutcome. The testsuite contains a number of testcases used to verify the implementation prior to integration with the national platform.
The testsuite uses SoapUI to verify the implementation. Documentation of SoapUI can be found at www.soapui.org.
Click here to download. Install according to documentation.
Prior to running the testcases in SoapUI, the data used in requests must be adjusted to conform to the current system under test. This can be done by editing the file data.xml as described below.
In the beginning of the document is a section called "globaldata". This is where you specify data that is used by all testcases.
Each element in "globaldata" can be overridden in a specific testcase if needs be. The following elements are global:
The only requirement on test data is that there is some data for the given patientId.
It might be a good idea to start by executing this testcase for a patient with a very simple response and when that works switch to a patient with more complex data.
"Begränsning av sökningen i tid. Begränsningen sker genom att resultatet innehåller
de poster vars, av förekommande tidfält analys/analysisTime , bildade tidsintervall till någon del
överlappar med det tidsintervall som anges i begäran. Ändpunkterna inkluderas i respektive intervall."
Additional information about failed assertions can be found in the script log.
The LaboratoryOutcome-elements below are recommended for the test, but you may skip those that are not applicable, e.g if the tested system does not
support start AND end time. You may also supply several elements of the same type, e.g. to test dates exactly on the boundary.
The expected DocumentId's, case 1 and 4 above, must be added as a comma-separated list in the
expectedDocumentIds field.
The unexpected DocumentId's, case 2,3 and 5 above, must be added as a comma-separated list in the
unexpectedDocumentIds field.
The fields httpHeaderHsaId and logicalAddress must contain values that do not limit the response.
Enter a PatientId, CareContactId and sourceSystemHSAid that exist in the source system.
The fields httpHeaderHsaId and logicalAddress must contain values that do not affect the returned list.
Enter a PatientId and CareUnitId that exist in the source system.
The fields httpHeaderHsaId and logicalAddress must contain values that do not affect the returned list.
Enter a PatientId that is not found in the source system and valid values for httpHeaderHsaId and logical adress.
Enter a PatientId that exists in the source system and a CareContactId and sourceSystemHSAid that is not found in the source system.
The fields httpHeaderHsaId and logicalAddress must contain values that do not affect the returned list.
This testcase can be recorded as not applicable if this kind of filtering does not take place in the tested system.
Enter a PatientId that has more than one LaboratoryorderOutcome-record in the source system.
Add one or more CareUnitIds that must be included in the response based on the
filtering rules to the field 'expectedCareUnitIds'.
Add one or more CareUnitIds of records that must not be included in the response based on the
filtering rules to the field 'unexpectedCareUnitIds'.
The field logicalAddress must contain a value that does not affect the list.
Enter a PatientId/CareContactId-combination that exists in the source system and valid values for httpHeaderHsaId and logicalAddress.
Enter PatientId and a CareContactId and the correct SourceSystemHSAId of a CareContact that is found in the source system.
The field logicalAddress must NOT match SourceSystemHSAid.
The field httpHeaderHsaId must contain a valid value.