Updated versions and operationId to r1.2

camaraproject · Aug 29, 2024 · c90a378 · c90a378
1 parent 897366d
commit c90a378
Show file tree

Hide file tree

Showing 11 changed files with 53 additions and 53 deletions.
diff --git a/code/Test_definitions/qod-provisioning-createProvisioning.feature b/code/Test_definitions/qod-provisioning-createProvisioning.feature
@@ -1,4 +1,4 @@
-Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation createProvisioning
+Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation createProvisioning
     # Input to be provided by the implementation to the tester
     #
     # Implementation indications:
@@ -14,7 +14,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation createProvisioning
 
     Background: Common createProvisioning setup
         Given an environment at "apiRoot"
-        And the resource "/qod-provisioning/v0.1rc1/device-qos"                                                              |
+        And the resource "/qod-provisioning/v0.1/device-qos"                                                              |
         And the header "Content-Type" is set to "application/json"
         And the header "Authorization" is set to a valid access token
         And the header "x-correlator" is set to a UUID value

diff --git a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature
@@ -1,4 +1,4 @@
-Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation deleteProvisioning
+Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation deleteProvisioning
     # Input to be provided by the implementation to the tester
     #
     # Implementation indications:
@@ -12,7 +12,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation deleteProvisioning
 
     Background: Common deleteProvisioning setup
         Given an environment at "apiRoot"
-        And the resource "/qod-provisioning/v0.1rc1/device-qos/{provisioningId}"
+        And the resource "/qod-provisioning/v0.1/device-qos/{provisioningId}"
         # Unless indicated otherwise the QoD provisioning must be created by the same API client given in the access token
         And the header "Authorization" is set to a valid access token granted to the same client that created the QoD provisoning
         And the header "x-correlator" is set to a UUID value

diff --git a/code/Test_definitions/qod-provisioning-getProvisioningById.feature b/code/Test_definitions/qod-provisioning-getProvisioningById.feature
@@ -1,4 +1,4 @@
-Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation getProvisioningById
+Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation getProvisioningById
     # Input to be provided by the implementation to the tester
     #
     # Implementation indications:
@@ -11,7 +11,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation getProvisioningByI
 
     Background: Common getProvisioningById setup
         Given an environment at "apiRoot"
-        And the resource "/qod-provisioning/v0.1rc1/device-qos/{provisioningId}"                                                              |
+        And the resource "/qod-provisioning/v0.1/device-qos/{provisioningId}"                                                              |
         # Unless indicated otherwise the QoD provisioning must be created by the same API client given in the access token
         And the header "Authorization" is set to a valid access token granted to the same client that created the QoD provisoning
         And the header "x-correlator" is set to a UUID value

diff --git a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature
@@ -1,4 +1,4 @@
-Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioningByDevice
+Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation retrieveProvisioningByDevice
     # Input to be provided by the implementation to the tester
     #
     # Implementation indications:
@@ -15,7 +15,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioni
 
     Background: Common retrieveProvisioningByDevice setup
         Given an environment at "apiRoot"
-        And the resource "/qod-provisioning/v0.1rc1/retrieve-device-qos"                                                              |
+        And the resource "/qod-provisioning/v0.1/retrieve-device-qos"                                                              |
         And the header "Content-Type" is set to "application/json"
         # Unless indicated otherwise the QoD provisioning must be created by the same API client given in the access token
         And the header "Authorization" is set to a valid access token granted to the same client that created the QoD provisoning

diff --git a/code/Test_definitions/qos-profiles-getQosProfile.feature b/code/Test_definitions/qos-profiles-getQosProfile.feature
@@ -1,4 +1,4 @@
-Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation getQosProfile
+Feature: CAMARA QoS Profiles API, v0.11.0 - Operation getQosProfile
     # Input to be provided by the implementation to the tester
     #
     # Implementation indications:
@@ -11,7 +11,7 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation getQosProfile
 
     Background: Common getQosProfile setup
         Given an environment at "apiRoot"
-        And the resource "qos-profiles/v0.11rc1/qos-profiles/{name}"
+        And the resource "qos-profiles/v0.11/qos-profiles/{name}"
         And the header "Authorization" is set to a valid access token
         And the header "x-correlator" is set to a UUID value
         And the path param "name" is set by default to a existing QoS profile name

diff --git a/...ns/qos-profiles-qosProfilesDevice.feature → .../qos-profiles-retrieveQoSProfiles.feature b/...ns/qos-profiles-qosProfilesDevice.feature → .../qos-profiles-retrieveQoSProfiles.feature
@@ -1,4 +1,4 @@
-Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
+Feature: CAMARA QoS Profiles API, v0.11.0 - Operation retrieveQoSProfiles
     # Input to be provided by the implementation to the tester
     #
     # Implementation indications:
@@ -14,9 +14,9 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
 
     # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0-rc.1
 
-    Background: Common qosProfilesDevice setup
+    Background: Common retrieveQoSProfiles setup
         Given an environment at "apiRoot"
-        And the resource "qos-profiles/v0.11rc1/qos-profiles"
+        And the resource "qos-profiles/v0.11/retrieve-qos-profiles"
         And the header "Content-Type" is set to "application/json"
         And the header "Authorization" is set to a valid access token
         And the header "x-correlator" is set to a UUID value
@@ -25,33 +25,33 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
 
     # Success scenarios
 
-    @qos_profiles_qosProfilesDevice_01_generic_success_scenario
+    @qos_profiles_retrieveQoSProfiles_01_generic_success_scenario
     Scenario: Common validations for any sucess scenario
         # Valid testing device and default request body compliant with the schema
         Given a request body compliant with the schema at "/components/schemas/QosProfileDeviceRequest"
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 200
         And the response header "Content-Type" is "application/json"
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And each item of the the response array, if any, complies with the OAS schema at "/components/schemas/QosProfile"
     # TBC: Add additional constraints, such as max* properties must be higher than min* equivalent properties, etc
 
-    @qos_profiles_qosProfilesDevice_02_filter_by_name_only
+    @qos_profiles_retrieveQoSProfiles_02_filter_by_name_only
     Scenario: Retrieve QoS profiles only by name
         Given the request body property "$.name" is set to an existing QoS profile name
         And the request body properties "$.device" and "$.status" are not included
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 200
         And the response header "Content-Type" is "application/json"
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response array has only one item which complies with the OAS schema at "/components/schemas/QosProfile"
         And the response property "$[0].name" value is equal to the request body property "$.name"
 
-    @qos_profiles_qosProfilesDevice_03_filter_by_status_only
+    @qos_profiles_retrieveQoSProfiles_03_filter_by_status_only
     Scenario Outline: Retrieve QoS profiles only by status
         Given the request body property "$.status" is set to the value <status>
         And the request body properties "$.device" and "$.name" are not included
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 200
         And the response header "Content-Type" is "application/json"
         And the response header "x-correlator" has same value as the request header "x-correlator"
@@ -64,34 +64,34 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
             | INACTIVE   |
             | DEPRECATED |
 
-    @qos_profiles_qosProfilesDevice_04_return_restricted_profiles
+    @qos_profiles_retrieveQoSProfiles_04_return_restricted_profiles
     Scenario: Return QoS Profiles restricted to certain devices
         Given that implementation has QoS Profiles restricted to certain devices
         And a device suitable for the restricted QoS Profiles is provided in the request body or identified by the access token
         And the request body properties "$.name" and "$.status" are not included
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 200
         And the response header "Content-Type" is "application/json"
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And each item of the the response array complies with the OAS schema at "/components/schemas/QosProfile"
         And the restricted QoS Profiles is returned in the response
 
-    @qos_profiles_qosProfilesDevice_05_not_return_restricted_profiles
+    @qos_profiles_retrieveQoSProfiles_05_not_return_restricted_profiles
     Scenario: Do not return restricted QoS Profiles restricted to certain devices
         Given that implementation has QoS Profiles restricted to certain devices
         And no device is provided in the request body or identified by the access token
         And the request body properties "$.name" and "$.status" are not included
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 200
         And the response header "Content-Type" is "application/json"
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And each item of the the response array complies with the OAS schema at "/components/schemas/QosProfile"
         And no restricted QoS Profile is included in the response
 
-    @qos_profiles_qosProfilesDevice_06_device_qos_profiles_not_found
+    @qos_profiles_retrieveQoSProfiles_06_device_qos_profiles_not_found
     Scenario: Device has not QoS profiles associated
         Given a device for which the service is not applicable, provided in the request body or identified by the access token
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 200
         And the response header "Content-Type" is "application/json"
         And the response header "x-correlator" has same value as the request header "x-correlator"
@@ -100,32 +100,32 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
 
     # Errors 400
 
-    @qos_profiles_qosProfilesDevice_400.1_schema_not_compliant
+    @qos_profiles_retrieveQoSProfiles_400.1_schema_not_compliant
     Scenario: Invalid Argument. Generic Syntax Exception
         Given the request body is set to any value which is not compliant with the schema at "/components/schemas/QosProfileDeviceRequest"
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 400
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
         And the response property "$.code" is "INVALID_ARGUMENT"
         And the response property "$.message" contains a user friendly text
 
-    @qos_profiles_qosProfilesDevice_400.2_no_request_body
+    @qos_profiles_retrieveQoSProfiles_400.2_no_request_body
     Scenario: Missing request body
         Given the request body is not included
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 400
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
         And the response property "$.status" is 400
         And the response property "$.code" is "INVALID_ARGUMENT"
         And the response property "$.message" contains a user friendly text
 
-    @qos_profiles_qosProfilesDevice_400.3_device_identifiers_not_schema_compliant
+    @qos_profiles_retrieveQoSProfiles_400.3_device_identifiers_not_schema_compliant
     # Test every type of identifier even if not supported by the implementation
     Scenario Outline: Some device identifier value does not comply with the schema
         Given the request body property "<device_identifier>" does not comply with the OAS schema at "<oas_spec_schema>"
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 400
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
@@ -142,11 +142,11 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
 
     # Generic 401 errors
 
-    @qos_profiles_qosProfilesDevice_401.1_no_authorization_header
+    @qos_profiles_retrieveQoSProfiles_401.1_no_authorization_header
     Scenario: Error response for no header "Authorization"
         Given the header "Authorization" is not sent
         And the request body is set to a valid request body
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 401
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
@@ -155,23 +155,23 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
         And the response property "$.message" contains a user friendly text
 
     # In this case both codes could make sense depending on whether the access token can be refreshed or not
-    @qos_profiles_qosProfilesDevice_401.2_expired_access_token
+    @qos_profiles_retrieveQoSProfiles_401.2_expired_access_token
     Scenario: Error response for expired access token
         Given the header "Authorization" is set to an expired access token
         And the request body is set to a valid request body
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 401
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
         And the response property "$.status" is 401
         And the response property "$.code" is "UNAUTHENTICATED" or "AUTHENTICATION_REQUIRED"
         And the response property "$.message" contains a user friendly text
 
-    @qos_profiles_qosProfilesDevice_401.3_invalid_access_token
+    @qos_profiles_retrieveQoSProfiles_401.3_invalid_access_token
     Scenario: Error response for invalid access token
         Given the header "Authorization" is set to an invalid access token
         And the request body is set to a valid request body
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 401
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
@@ -182,12 +182,12 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
 
     # Errors 403
 
-    @qos_profiles_qosProfilesDevice_403.1_device_token_mismatch
+    @qos_profiles_retrieveQoSProfiles_403.1_device_token_mismatch
     Scenario: Inconsistent access token context for the device
         # To test this, a token have to be obtained for a different device
         Given the request body property "$.device" is set to a valid testing device
         And the header "Authorization" is set to a valid access token emitted for a different device
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 403
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
@@ -198,11 +198,11 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
     # Errors 422
 
     # UNSUPPORTED_DEVICE_IDENTIFIERS is in the Commonalities guidelines (document) but it is not yet considered in the API spec
-    @qos_profiles_qosProfilesDevice_422.1_device_identifiers_unsupported
+    @qos_profiles_retrieveQoSProfiles_422.1_device_identifiers_unsupported
     Scenario: None of the provided device identifiers is supported by the implementation
         Given that some type of device identifiers are not supported by the implementation
         And the request body property "$.device" only includes device identifiers not supported by the implementation
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 422
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"
@@ -211,11 +211,11 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice
         And the response property "$.message" contains a user friendly text
 
     # This scenario is under discussion
-    @qos_profiles_qosProfilesDevice_422.2_device_identifiers_mismatch
+    @qos_profiles_retrieveQoSProfiles_422.2_device_identifiers_mismatch
     Scenario: Device identifiers mismatch
         Given that al least 2 types of device identifiers are supported by the implementation
         And the request body property "$.device" includes several identifiers, each of them identifying a valid but different device
-        When the request "qosProfilesDevice" is sent
+        When the request "retrieveQoSProfiles" is sent
         Then the response status code is 422
         And the response header "x-correlator" has same value as the request header "x-correlator"
         And the response header "Content-Type" is "application/json"

diff --git a/code/Test_definitions/quality-on-demand-createSession.feature b/code/Test_definitions/quality-on-demand-createSession.feature
@@ -1,4 +1,4 @@
-Feature: CAMARA Quality On Demand API, v0.11.0-rc.1 - Operation createSession
+Feature: CAMARA Quality On Demand API, v0.11.0 - Operation createSession
     # Input to be provided by the implementation to the tester
     #
     # Implementation indications:
@@ -15,7 +15,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0-rc.1 - Operation createSession
 
     Background: Common createSession setup
         Given an environment at "apiRoot"
-        And the resource "/quality-on-demand/v0.11rc1/sessions"
+        And the resource "/quality-on-demand/v0.11/sessions"
         And the header "Content-Type" is set to "application/json"
         And the header "Authorization" is set to a valid access token
         And the header "x-correlator" is set to a UUID value