FI-3010: Split out Subscription Rejection tests

lib/subscriptions_test_kit/requirements/generated/subscriptions-test-kit_requirements_coverage.csv

@@ -5,12 +5,12 @@ hl7.fhir.uv.subscriptions_1.1.0,4,https://hl7.org/fhir/uv/subscriptions-backport
 hl7.fhir.uv.subscriptions_1.1.0,7,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,"When a FHIR Server accepts a request to create a Subscription, the server is indicating to the client that the server:
  - is capable of detecting when events covered by the requested SubscriptionTopic occur, and
  - is willing to make a simple best effort attempt at delivering a notification for each occurrence of a matching event.",SHALL,Server,,,NA,NA,"1.1.03, 3.1.1.03, 3.2.1.03, 3.3.1.03","subscriptions_r5_backport_r4_server-subscriptions_r4_server_workflow-subscriptions_r4_server_interaction-subscriptions_r4_server_creation_response_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_empty_content-subscriptions_r4_server_empty_content_interaction-subscriptions_r4_server_creation_response_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_id_only_content-subscriptions_r4_server_id_only_content_interaction-subscriptions_r4_server_creation_response_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_full_resource_content-subscriptions_r4_server_full_resource_content_interaction-subscriptions_r4_server_creation_response_conformance"
-hl7.fhir.uv.subscriptions_1.1.0,8,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that the SubscriptionTopic is valid and implemented by the server,SHOULD,Server,,,NA,NA,6.01,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscriptions
-hl7.fhir.uv.subscriptions_1.1.0,9,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that all requested filters are defined in the requested topic and are implemented in the server,SHOULD,Server,,,NA,NA,6.01,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscriptions
-hl7.fhir.uv.subscriptions_1.1.0,10,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that the channel type is known and implemented by the server,SHOULD,Server,,,NA,NA,6.01,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscriptions
-hl7.fhir.uv.subscriptions_1.1.0,11,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,"When processing a request for a Subscription...a server SHOULD validate…that the channel endpoint is valid for the channel provided (e.g., is it a valid URL of the expected type)",SHOULD,Server,,,NA,NA,6.01,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscriptions
-hl7.fhir.uv.subscriptions_1.1.0,12,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that the payload configuration is known and implemented by the server,SHOULD,Server,,,NA,NA,6.01,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscriptions
-hl7.fhir.uv.subscriptions_1.1.0,13,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,"When processing a request for a Subscription...a server SHOULD validate…that the payload configuration is valid for the channel type requested (e.g., complies with the server’s security policy)",SHOULD,Server,,,NA,NA,6.01,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscriptions
+hl7.fhir.uv.subscriptions_1.1.0,8,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that the SubscriptionTopic is valid and implemented by the server,SHOULD,Server,,,NA,NA,6.02,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscription_topic
+hl7.fhir.uv.subscriptions_1.1.0,9,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that all requested filters are defined in the requested topic and are implemented in the server,SHOULD,Server,,,NA,NA,6.03,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscription_filter
+hl7.fhir.uv.subscriptions_1.1.0,10,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that the channel type is known and implemented by the server,SHOULD,Server,,,NA,NA,6.04,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscription_channel_type
+hl7.fhir.uv.subscriptions_1.1.0,11,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,"When processing a request for a Subscription...a server SHOULD validate…that the channel endpoint is valid for the channel provided (e.g., is it a valid URL of the expected type)",SHOULD,Server,,,NA,NA,6.05,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscription_channel_endpoint
+hl7.fhir.uv.subscriptions_1.1.0,12,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,When processing a request for a Subscription...a server SHOULD validate…that the payload configuration is known and implemented by the server,SHOULD,Server,,,NA,NA,6.06,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscription_payload_type
+hl7.fhir.uv.subscriptions_1.1.0,13,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#accepting-subscription-requests,"When processing a request for a Subscription...a server SHOULD validate…that the payload configuration is valid for the channel type requested (e.g., complies with the server’s security policy)",SHOULD,Server,,,NA,NA,6.07,subscriptions_r5_backport_r4_server-subscriptions_r4_server_subscription_rejection-subscriptions_r4_server_reject_subscription_channel_payload_combo
 hl7.fhir.uv.subscriptions_1.1.0,14,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#subscription-notifications,"In ... FHIR R4 ... notifications are based on a history Bundle. The first entry always contains SubscriptionStatus information, encoded as ... a Parameters resource using the Backport SubscriptionStatus Profile in FHIR R4",SHALL,Server,,,NA,NA,"1.2.01, 3.1.2.01, 3.1.2.02, 3.2.2.01, 3.2.2.02, 3.3.2.01, 3.3.2.02, 4.01, 4.02","subscriptions_r5_backport_r4_server-subscriptions_r4_server_workflow-subscriptions_r4_server_interaction_verification-subscriptions_r4_server_notification_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_empty_content-subscriptions_r4_server_empty_content_interaction_verification-subscriptions_r4_server_notification_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_empty_content-subscriptions_r4_server_empty_content_interaction_verification-subscriptions_r4_server_empty_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_id_only_content-subscriptions_r4_server_id_only_content_interaction_verification-subscriptions_r4_server_notification_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_id_only_content-subscriptions_r4_server_id_only_content_interaction_verification-subscriptions_r4_server_id_only_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_full_resource_content-subscriptions_r4_server_full_resource_content_interaction_verification-subscriptions_r4_server_notification_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_event_notification-subscriptions_r4_server_full_resource_content-subscriptions_r4_server_full_resource_content_interaction_verification-subscriptions_r4_server_full_resource_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_handshake_heartbeat-subscriptions_r4_server_handshake_conformance, subscriptions_r5_backport_r4_server-subscriptions_r4_server_handshake_heartbeat-subscriptions_r4_server_heartbeat_conformance"
 hl7.fhir.uv.subscriptions_1.1.0,15,https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/components.html#subscription-notifications,"Note that since notifications use history type Bundles, all notifications need to comply with the requirements for that bundle type. Specifically, there are two invariants on Bundle (bdl-3 and bdl-4) that require a Bundle.entry.request element for every Bundle.entry. 
 - For the status resource (entry[0]) the request SHALL be filled out to match a request to the $status operation. 

lib/subscriptions_test_kit/suites/subscriptions_r5_backport_r4_server/common/subscription_creation.rb

@@ -16,6 +16,12 @@ def get_new_subscription_value(subscription, field_path)
         field_path.reduce(subscription) { |obj, path| obj[path] }
       end
 
+      def normalize_value(value)
+        return value.deep_transform_keys(&:to_sym) if value.is_a?(Hash)
+
+        value
+      end
+
       def send_unsupported_subscription(subscription, unsupported_type, field_paths, subscription_field_old_values)
         fhir_operation('/Subscription', body: subscription)
 
@@ -27,7 +33,10 @@ def send_unsupported_subscription(subscription, unsupported_type, field_paths, s
         altered_field = false
         field_paths.each_with_index do |field_path, index|
           subscription_field_new_value = get_new_subscription_value(new_subscription, field_path)
-          if subscription_field_new_value != subscription_field_old_values[index]
+          new_value = normalize_value(subscription_field_new_value)
+          old_value = normalize_value(subscription_field_old_values[index])
+
+          if new_value != old_value
             altered_field = true
             break
           end

lib/subscriptions_test_kit/suites/subscriptions_r5_backport_r4_server/subscription_rejection/reject_subscription_channel_endpoint_test.rb

@@ -0,0 +1,65 @@
+require_relative '../common/subscription_creation'
+
+module SubscriptionsTestKit
+  module SubscriptionsR5BackportR4Server
+    class RejectSubscriptionChannelEndpointTest < Inferno::Test
+      include SubscriptionCreation
+
+      id :subscriptions_r4_server_reject_subscription_channel_endpoint
+      title 'Server Handles Unsupported Subscription Channel Endpoints'
+      description %(
+        When processing a request for a Subscription a server SHOULD verify that the Subscription is supported and does
+        not contain any information not implemented by the server. If the Subscription is not supported, the server
+        should reject the Subscription create request, or it should attempt to adjust the Subscription. When
+        processing a request for a Subscription, a server SHOULD validate that the channel endpoint is valid
+        for the channel provided (e.g., is it a valid URL of the expected type).
+
+        The test will pass if the server either
+        1. rejects the Subscription by responding with a non-201 response, or
+        2. updates the Subscription resource to remove or replace the unsupported value.
+      )
+
+      verifies_requirements 'hl7.fhir.uv.subscriptions_1.1.0@11'
+
+      input :subscription_resource,
+            title: 'Workflow Subscription Resource',
+            type: 'textarea',
+            description: %(
+              A Subscription resource in JSON format that Inferno will send to the server under test
+              so that it can demonstrate its ability to perform the Subscription creation and Notification
+              response workflow. The instance must be conformant to the R4/B Topic-Based Subscription profile.
+              Inferno may modify the Subscription before submission, e.g., to point to Inferno's notification endpoint.
+              This input is also used by the unsupported Subscription test as the base on which to add unsupported
+              element values to test for server rejection.
+            )
+      input :unsupported_subscription_channel_endpoint,
+            title: 'Unsupported Subscription Channel Endpoint',
+            description: 'An unsupported value for the `channel.endpoint` element to test for Subscription rejection.',
+            optional: true
+
+      run do
+        skip_if(unsupported_subscription_channel_endpoint.blank?, %(
+          No subscription channel type and payload combo provided.))
+
+        assert_valid_json(subscription_resource)
+        subscription = JSON.parse(subscription_resource)
+
+        unsupported_info = {
+          'unsupported_title' => 'unsupported channel URL',
+          'field_path' => ['channel', 'endpoint'],
+          'field_value' => unsupported_subscription_channel_endpoint
+        }
+
+        field_name = unsupported_info['field_path'].last
+        outer_field_name = unsupported_info['field_path'].first
+        subscription_field = subscription[outer_field_name]
+        subscription_field[field_name] = unsupported_info['field_value']
+
+        send_unsupported_subscription(subscription, unsupported_info['unsupported_title'],
+                                      [unsupported_info['field_path']], [unsupported_info['field_value']])
+
+        no_error_verification('Unsupported Subscription creation error handling failures.')
+      end
+    end
+  end
+end

lib/subscriptions_test_kit/suites/subscriptions_r5_backport_r4_server/subscription_rejection/reject_subscription_channel_payload_combo_test.rb

@@ -0,0 +1,75 @@
+require_relative '../common/subscription_creation'
+
+module SubscriptionsTestKit
+  module SubscriptionsR5BackportR4Server
+    class RejectSubscriptionChannelPayloadComboTest < Inferno::Test
+      include SubscriptionCreation
+
+      id :subscriptions_r4_server_reject_subscription_channel_payload_combo
+      title 'Server Handles Unsupported Subscription Payload for Channel Type'
+      description %(
+        When processing a request for a Subscription a server SHOULD verify that the Subscription is supported and does
+        not contain any information not implemented by the server. If the Subscription is no supported, the server
+        should reject the Subscription create request, or it should attempt to adjust the Subscription. When
+        processing a request for a Subscription, a server SHOULD validate, that the payload configuration is
+        valid for the channel type requested (e.g., complies with the server's security policy).
+
+        The test will pass if the server either
+        1. rejects the Subscription by responding with a non-201 response, or
+        2. updates the Subscription resource to remove or replace the unsupported value.
+      )
+
+      verifies_requirements 'hl7.fhir.uv.subscriptions_1.1.0@13'
+
+      input :subscription_resource,
+            title: 'Workflow Subscription Resource',
+            type: 'textarea',
+            description: %(
+              A Subscription resource in JSON format that Inferno will send to the server under test
+              so that it can demonstrate its ability to perform the Subscription creation and Notification
+              response workflow. The instance must be conformant to the R4/B Topic-Based Subscription profile.
+              Inferno may modify the Subscription before submission, e.g., to point to Inferno's notification endpoint.
+              This input is also used by the unsupported Subscription test as the base on which to add unsupported
+              element values to test for server rejection.
+            )
+      input :unsupported_subscription_channel_payload_combo,
+            title: 'Unsupported Subscription Channel and Payload Combination',
+            description: %(
+              A channel (`channel.type`) and payload type (`content` extension under the `channel.payload` element)
+              combination not implemented by the server to test for Subscription
+              rejection. Provide in the json format e.g. {channel: <'channel_type'>, payload: <'payload_type'>}.
+            ),
+            optional: true
+
+      run do
+        skip_if(unsupported_subscription_channel_payload_combo.blank?, %(
+          No subscription channel type and payload combo provided.))
+
+        assert_valid_json(subscription_resource)
+        subscription = JSON.parse(subscription_resource)
+
+        assert_valid_json(unsupported_subscription_channel_payload_combo)
+        channel_payload_combo = JSON.parse(unsupported_subscription_channel_payload_combo)
+        channel_value = channel_payload_combo['channel']
+        payload_value = channel_payload_combo['payload']
+
+        if channel_value.blank? || payload_value.blank?
+          add_message('error', %(Channel and payload values are not populated correctly in unsupported channel and
+                                 payload combination input.))
+        else
+          subscription_channel = subscription['channel']
+          subscription_channel['type'] = channel_value
+          subscription_channel['payload'] = payload_value
+
+          channel_path = ['channel', 'type']
+          payload_path = ['channel', 'payload']
+
+          send_unsupported_subscription(subscription, 'unsupported channel and payload combination',
+                                        [channel_path, payload_path], [channel_value, payload_value])
+        end
+
+        no_error_verification('Unsupported Subscription creation error handling failures.')
+      end
+    end
+  end
+end