[albertoramosmonagas]

What type of PR is this?

• correction
• tests

What this PR does / why we need it:

The sim-swap-subscriptions test definitions for the event notification scenarios no longer match the subscription event schemas introduced by Commonalities. initiationReason and terminationReason are now properties of data in the notification, not response properties.

This PR:

• Refactors the following scenarios in sim-swap-subscriptions.feature:
  • @sim_swap_subscriptions_03_subscription_creation_event_validation
  • @sim_swap_subscriptions_08_subscription_ends_on_expiry
  • @sim_swap_subscriptions_09_subscription_ends_on_max_events
  • @sim_swap_subscriptions_10_subscription_delete_event_validation
• Specifies initiationReason and terminationReason as notification properties under $.data, instead of response properties.
• Adds a check of $.data.subscriptionId against the subscription identity.
• Reformulates the check of the notification type in the same way as the other property checks.
• Uses $.config.subscriptionMaxEvents and an explicit subscription identity in the Given steps of scenarios 08 and 09.
• Makes data a required property of EventSwapped, EventSubscriptionStarted, EventSubscriptionUpdated and EventSubscriptionEnded in sim-swap-subscriptions.yaml, as suggested in the issue.

Which issue(s) this PR fixes:

Fixes #326

Special notes for reviewers:

• The test wording follows the proposed fix in Fix issues with test definitions for event notifications Commonalities#749, which is still open. If the wording changes during its review, the scenarios here may need a small follow-up.
• Making data required only tightens the notification schemas. The data object was already always sent in these events, and no request or response schema changes.

Changelog input

release note
 Fix test definitions for subscription-started and subscription-ended event notifications in sim-swap-subscriptions and make data a required property of the event notification schemas in sim-swap-subscriptions

[albertoramosmonagas]

Hi @camaraproject/sim-swap_codeowners, a question on @sim_swap_subscriptions_swapped_event_validation.

This scenario validated the notification body against #/components/schemas/CloudEvent. That reference came from the Commonalities r4.4 template, where CloudEvent is used for the generic "initial event" scenario. The swapped event has its own schema in this API, EventSwapped, which is the one mapped by the ApiNotificationEvent discriminator for the swapped type. CloudEvent only checks the envelope and does not validate data.

In the last commit I changed the reference to #/components/schemas/EventSwapped, so that the scenario checks data (phoneNumber, subscriptionId) and the data.subscriptionId assertion is covered by the schema. Was CloudEvent intentional here? If so, I will revert that line.