Fanout_Test

Owned by Patrick Lobre
Last updated: Aug 30, 2019 by Eric McDonald
3 min read

Fanout_Test Test Details:

Overview:

Fanout_Test project is used for testing fan out functionality of Patient Discovery (PD) and Document Query (DQ) which will broadcast messages to all known exchanges to the initiating gateway.

Testing will be done in standard mode. 


Test Case Details:

  • DQ warmup: This test case is used to warm up Document Query by invoking the service and load all beans/services required. A basic check on the response to ensure the service passed its initialization by checking that the document ID's match.
  • DQ all: This test case is used to test the Document Query fanout functionality by using a standard mocked invocation. In this situation, all Home Community ID (HCID)'s used in the fanout test all point to the same local endpoint. Correlations are added for all the HCID's that are being used for test data and mappings for the HCIDs are added as assigned authorities. The adapter endpoint is mocked out for a standard response.  Once the requests are processed and aggregated, the test suite ensures the result is not an error state and that the DocID matches, the RegistryError count is correct, and the ExtrinsicObject count is correct.
  • DQ happy path: This test case is used to test the Document Query fanout functionality by using a standard mocked invocation. In this situation, all HCID's used in the fanout test all point to the same local endpoint. Correlations are added for all the HCID's that are being used for test data and mappings for the HCID's are added as assigned authorities. The adapter endpoint is mocked out for a standard response.  Once the requests are processed and aggregated, the test suite ensures the result is not an error state and that the DocID matches.
  • DQ no mock: This test case is used to test the Document Query fanout functionality by using a standard non-mocked invocation. In this situation, all HCID's used in the fanout test all point to the same local endpoint. Correlations are added for all the HCID's that are being used for test data and mappings for the HCID's are added as assigned authorities. Once the requests are processed and aggregated, the test suite ensures the result is not an error state.
  • PD warmup: This test case is used to warm up Patient Discovery by invoking the service and load all beans/services required. A basic check on the correlations database is done to ensure the service passed its initialization.
  • PD all: This test case is used to test the Patient Discovery fanout functionality by using standard, mocked invocation. In this situation, all HCID's used in the fanout test all point to the same local endpoint. The adapter endpoint is mocked out for a standard response. Once the requests are processed and aggregated, the test suite then does assertion checks on the Given Name, Family Name, and the number of asOtherIDs. A later step then counts the number of correlations and ensures the count is correct.
  • PD happy path: This test case is used to test the Patient Discovery fanout functionality by using standard, mocked invocation. In this situation, all HCID's used in the fanout test all point to the same local endpoint. The adapter endpoint is mocked out for a standard response. Once the requests are processed and aggregated, the test suite then does assertion checks on the Given Name, Family Name, and existence of the controlActProcess element. A later step then counts the number of correlations and ensures the count is correct.
  • PD no Mock: This test case is used to test the Patient Discovery fanout functionality by using standard, non-mocked invocation. In this situation, all HCIDs used in the fanout test all point to the same local endpoint. Once the requests are processed and aggregated, the test suite then does assertion checks on the Given Name, Family Name, and the number of asOtherIDs. A later step then counts the number of correlations and ensures the count is correct.

Preparation & Execution:

  1. Make sure to copy CONNECT common properties from \\CONNECT\Product\Production\Common\Properties\src\main\resources to application server properties folder. (If using WildFly 8.2.1 , copy into \\wildfly-8.2.1.Final\modules\system\layers\base\org\connectopensource\configuration\main).
  2. Make sure to enable Standard mode for PD and DQ services in gateway.properties. Note: By default all services will be in Standard mode in gateway.properties as of CONNECT-4.6 release.
  3. Restart application server.
  4. Deploy CONNECT ear (mvn clean install -P AD,DQ,DR,DS,PD).
  5. In SoapUI, make sure to have GatewayPropDir value set either by using global SOAPUI properties or by setting custom SOAPUI property at the project level.
  6. In SoapUI, load Fanout_Test project and execute.
  7. Make sure all test cases are passed and green.