From 6f236acd6331cb9eaf181a303c6811afe809f906 Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Thu, 22 Aug 2024 11:19:12 +0200 Subject: [PATCH 1/7] QoD Test definitions --- code/Test_definitions/QoD_API_Test.feature | 70 ---- code/Test_definitions/README.md | 18 +- ...od-provisioning-createProvisioning.feature | 344 ++++++++++++++++ ...od-provisioning-deleteProvisioning.feature | 165 ++++++++ ...d-provisioning-getProvisioningById.feature | 127 ++++++ ...oning-retrieveProvisioningByDevice.feature | 258 ++++++++++++ .../qos-profiles-getQosProfile.feature | 108 +++++ .../qos-profiles-qosProfilesDevice.feature | 224 +++++++++++ .../quality-on-demand-createSession.feature | 374 ++++++++++++++++++ .../quality-on-demand-deleteSession.feature | 126 ++++++ ...on-demand-extendQosSessionDuration.feature | 194 +++++++++ .../quality-on-demand-getSession.feature | 133 +++++++ ...on-demand-retrieveSessionsByDevice.feature | 259 ++++++++++++ 13 files changed, 2329 insertions(+), 71 deletions(-) delete mode 100644 code/Test_definitions/QoD_API_Test.feature create mode 100644 code/Test_definitions/qod-provisioning-createProvisioning.feature create mode 100644 code/Test_definitions/qod-provisioning-deleteProvisioning.feature create mode 100644 code/Test_definitions/qod-provisioning-getProvisioningById.feature create mode 100644 code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature create mode 100644 code/Test_definitions/qos-profiles-getQosProfile.feature create mode 100644 code/Test_definitions/qos-profiles-qosProfilesDevice.feature create mode 100644 code/Test_definitions/quality-on-demand-createSession.feature create mode 100644 code/Test_definitions/quality-on-demand-deleteSession.feature create mode 100644 code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature create mode 100644 code/Test_definitions/quality-on-demand-getSession.feature create mode 100644 code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature diff --git a/code/Test_definitions/QoD_API_Test.feature b/code/Test_definitions/QoD_API_Test.feature deleted file mode 100644 index fdc6e40750..0000000000 --- a/code/Test_definitions/QoD_API_Test.feature +++ /dev/null @@ -1,70 +0,0 @@ -#/*- ---license-start -#* CAMARA Project -#* --- -#* Copyright (C) 2022 - 2023 Contributors | Deutsche Telekom AG to CAMARA a Series of LF Projects, LLC -#* The contributor of this file confirms his sign-off for the -#* Developer Certificate of Origin (http://developercertificate.org). -#* --- -#* Licensed under the Apache License, Version 2.0 (the "License"); -#* you may not use this file except in compliance with the License. -#* You may obtain a copy of the License at -#* -#* http://www.apache.org/licenses/LICENSE-2.0 -#* -#* Unless required by applicable law or agreed to in writing, software -#* distributed under the License is distributed on an "AS IS" BASIS, -#* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -#* See the License for the specific language governing permissions and -#* limitations under the License. -#* ---license-end -#*/ - -@QoD @QoDSanity -Feature: Automated QoD System Integration Test - - @QQoDSessionCreateGetDelete - Scenario: Create QoD session with mandatory parameters - Given Use the QoD MOCK URL - When Create a new QoD session with mandatory parameters - Then Response code is 201 - When Get QoD session - Then Response code is 200 - When Delete existing QoD session - Then Response code is 204 - - @QoDSessionCreateGetDeleteAllparams - Scenario: Create QoD session with all parameters & Deletion of Session id - Given Use the QoD MOCK URL - When Create a new QoD session with all parameters - Then Response code is 201 - When Get QoD session - Then Response code is 200 - When Delete existing QoD session - Then Response code is 204 - - @QoDCreateSessionDeleteInvalidSession - Scenario: Delete a Invalid QoD session for session id - Given Use the QoD MOCK URL - When Create a new QoD session with mandatory parameters - Then Response code is 201 - When Delete Invalid QoD session - Then Response code is 404 - - - @QoDInvalidCreateSession - Scenario: QoD session with 5XX response - # Test with end point not reachable - Given Use the QoD MOCK URL with invalid scenario - When Create a new QoD session along with all parameters - Then Response code is 500 - - - @QoDInvalidCreateSessionpayload - Scenario: QoD session with invalid payload 4XX - # Test with invalid Payload - Given Use the QoD MOCK URL with invalid scenario - When Create a new QoD session with parameters - Then Response code is 400 - - - diff --git a/code/Test_definitions/README.md b/code/Test_definitions/README.md index 27a1f06586..20be4f6345 100644 --- a/code/Test_definitions/README.md +++ b/code/Test_definitions/README.md @@ -1 +1,17 @@ -This directory contains at least one `.feature` file containing test definitions for the repository API(s). +This directory contains the `.feature` files with test definitions for the 3 repository API(s). +There is a separate Feature file per API operation. + +The test plan has to be enhanced and some scenarios still contains comments and questions to be resolved: + +* Should `sinkCredential` be returned as part of `SessionInfo` and `ProvisioningInfo` responses? +* For port ranges, the maximum is considered in the schema so a generic schema validator may generate a 400 INVALID_ARGUMENT without further distinction, instead of the specific 400 OUT_OF_RANGE, so both could be accepted +* For `sinkCredential.accessTokenType`, only `bearer` is considered in the schema so a generic schema validator may generate a 400 INVALID_ARGUMENT without further distinction, instead of the specific 400 INVALID_TOKEN, so both could be accepted +* When providing a non existent QoS Profile to create a session or provisioning, what code to return? 400 INVALID_ARGUMENT is proposed +* For expired tokens, both codes "UNAUTHENTICATED" or "AUTHENTICATION_REQUIRED" for 401 may be returned, depending on whether the access token can be refreshed or not +* Decision about 422 DEVICE_IDENTIFIERS_MISMATCH is under discussion +* Now that QoS Profiles may be restricted to certain devices, what code to return when the provided device in createSession is not suitable for the provided qosProfile. We may reuse 422 DEVICE_NOT_APPLICABLE +* When providing a path parameter, such sessionId or provisioningId, which is not compliant with the spec format (UUID), what code to return? Options are 400 INVALID_ARGUMENT or 404 NOT_FOUND if path parameter format is not checked previously +* 422 UNSUPPORTED_DEVICE_IDENTIFIERS is in the Commonalities guidelines (document) but it is not yet in the artifact and it not yet considered in the quality-on-demand or qos-profiles API specs, but it is in qod-provisioning API spec +* It is not defined the expected behavior when extending the duration of a session in qosStatus REQUESTED or UNAVAILABLE +* For QoS Profile response validations, it is pending to check additional constraints, such as minDuration being less or equal than maxDuration, etc + diff --git a/code/Test_definitions/qod-provisioning-createProvisioning.feature b/code/Test_definitions/qod-provisioning-createProvisioning.feature new file mode 100644 index 0000000000..37f2d1bde6 --- /dev/null +++ b/code/Test_definitions/qod-provisioning-createProvisioning.feature @@ -0,0 +1,344 @@ +Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation createProvisioning + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # * List of device identifier types which are not supported, among: phoneNumber, ipv4Address, ipv6Address. + # For this version, CAMARA does not allow the use of networkAccessIdentifier, so it is considered by default as not supported. + # + # Testing assets: + # * A device object applicable for QoD provisioning service + # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any + # + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + + Background: Common createProvisioning setup + Given an environment at "apiRoot" + And the resource "/qod-provisioning/v0.1rc1/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 + # Properties not explicitly overwitten in the Scenarios can take any values compliant with the schema + And the request body is set by default to a request body compliant with the schema at "/components/schemas/CreateProvisioning" + + # Success scenarios + + @qod_provisioning_createProvisioning_01_generic_success_scenario + Scenario: Common validations for any sucess scenario + # Valid testing device and default request body compliant with the schema + Given a valid testing device supported by the service, identified by the token or provided in the request body + And the request property "$.qosProfile" is set to a valid QoS Profile as returned by QoS Profiles API + When the request "createProvisioning" is sent + Then the response status code is 201 + And the response header "x-correlator" has same value as the request header "x-correlator" + And the response header "Content-Type" is "application/json" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/ProvisioningInfo" + # Additionally any success response has to comply with some constraints beyond the schema compliance + And the response property "$.device" exists only if provided in the request body and with the same value + And the response property "$.qosProfile" has the same value as in the request body + And the response property "$.sink" exists only if provided in the request body and with the same value + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatible for security concerns + And the response property "$.startedAt" exists only if "$.status" is "AVAILABLE" and the value is in the past + And the response property "$.statusInfo" exists only if "$.status" is "UNAVAILABLE" + + @qod_provisioning_createProvisioning_02_event_notification + Scenario: Events for the outcome of provisioning creation if sink is provided + Given a valid testing device supported by the service, identified by the token or provided in the request body + And the request property "$.qosProfile" is set to a valid QoS Profile as returned by QoS Profiles API + And the request property "$.sink" is set to a URL when events can be monitored + And the request property "$.sinkCredentials.credentialType" is set to "ACCESSTOKEN" + And the request property "$.sinkCredentials.accessTokenType" is set to "bearer" + And the request property "$.sinkCredentials.accessToken" is set to a valid access token accepted by the events receiver + And the request property "$.sinkCredentials.accessTokenExpiresUtc" is set to a value long enough in the future + And the request "createProvisioning" is sent + And the response status code is 201 + # There is no specific limit defined for the process to end + When the provisioning outcome is known + Then an event is received at the address of the request property "$.sink" + And the event header "Authorization" is set to "Bearer: " + the value of the request property "$.sinkCredentials.accessToken" + And the event header "Content-Type" is set to "application/cloudevents+json" + And the event body complies with the OAS schema at "/components/schemas/EventStatusChanged" + # Additionally any event body has to comply with some constraints beyond the schema compliance + And the event body property "$.id" is unique + And the event body property "$.type" is set to "org.camaraproject.qod-provisioning.v0.status-changed" + And the event body property "$.data.provisioningId" has the same value as createProvisioning response property "$.provisioningId" + And the event body property "$.data.status" is "AVAILABLE" or "UNAVAILABLE" + And the event body property "$.data.statusInfo" exists only if "$.data.status" is "UNAVAILABLE" + + @qod_provisioning_createProvisioning_03_3_legged_missing_device + Scenario: Device is not returned if not included in the creation request + Given the header "Authorization" is set to a valid 3-legged access token associated to a valid testing device supported by the service + And the request property "$.device" is not included + When the request "createProvisioning" is sent + Then the response status code is 201 + 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 body complies with the OAS schema at "/components/schemas/ProvisioningInfo" + And the response property "$.device" does not exist + + # Errors 400 + + @qod_provisioning_createProvisioning_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/CreateProvisioning" + When the request "createProvisioning" 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 + + @qod_provisioning_createProvisioning_400.2_no_request_body + Scenario: Missing request body + Given the request body is not included + When the request "createProvisioning" 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 + + @qod_provisioning_createProvisioning_400.3_empty_request_body + Scenario: Empty object as request body + Given the request body is set to {} + When the request "createProvisioning" 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 + + @qod_provisioning_createProvisioning_400.4_device_empty + Scenario Outline: The device value is an empty object + Given the request body property "$.device" is set to: {} + When the request "createProvisioning" 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 + + @qod_provisioning_createProvisioning_400.5_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 "" does not comply with the OAS schema at "" + When the request "createProvisioning" 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 + + Examples: + | device_identifier | oas_spec_schema | + | $.device.phoneNumber | /components/schemas/PhoneNumber | + | $.device.ipv4Address | /components/schemas/NetworkAccessIdentifier | + | $.device.ipv6Address | /components/schemas/DeviceIpv4Addr | + | $.device.networkIdentifier | /components/schemas/DeviceIpv6Address | + + # The maximum is considered in the schema so a generic schema validator may fail and generate a 400 INVALID_ARGUMENT without further distinction, and both could be accepted + @qod_provisioning_createProvisioning_400.6_out_of_range_port + Scenario: Out of range port + Given the request body property "$.device.ipv4Address.publicPort" is set to a value higher than 65535 + When the request "createProvisioning" 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 "OUT_OF_RANGE" or "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + # PLAIN and REFRESHTOKEN are considered in the schema so INVALID_ARGUMENT is not expected + @qod_provisioning_createProvisioning_400.7_invalid_sink_credential + Scenario Outline: Invalid credential + Given the request body property "$.sinkCredential.credentialType" is set to "" + When the request "createProvisioning" 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_CREDENTIAL" + And the response property "$.message" contains a user friendly text + + Examples: + | unsupported_credential_type | + | PLAIN | + | REFRESHTOKEN | + + # Only "bearer" is considered in the schema so a generic schema validator may fail and generate a 400 INVALID_ARGUMENT without further distinction, + # and both could be accepted + @qod_provisioning_createProvisioning_400.8_sink_credential_invalid_token + Scenario: Invalid token + Given the request body property "$.sinkCredential.accessTokenType" is set to a value other than "bearer" + When the request "createProvisioning" 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_TOKEN" or "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + + # TBD if we neeed a dedicated code + @quality-on-demand_createSession_400.9_non_existent_qos_profile + Scenario: Non existent QoS profile + Given the request body property "qosProfile" is set to a non-existent QoS Profile + When the request "createProvisioning" 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 + + # Generic 401 errors + + @qod_provisioning_createProvisioning_401.1_no_authorization_header + Scenario: No Authorization header + Given the header "Authorization" is removed + When the request "createProvisioning" 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" + 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 + @qod_provisioning_createProvisioning_401.2_expired_access_token + Scenario: Expired access token + Given the header "Authorization" is set to an expired access token + When the request "createProvisioning" 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 + + @qod_provisioning_createProvisioning_401.3_invalid_access_token + Scenario: Invalid access token + Given the header "Authorization" is set to an invalid access token + When the request "createProvisioning" 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" + And the response property "$.message" contains a user friendly text + + # Errors 403 + + @qod_provisioning_createProvisioning_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 "createProvisioning" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "INVALID_TOKEN_CONTEXT" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + # Typically with a 2-legged access token + @qod_provisioning_createProvisioning_404.1_device_not_found + Scenario: Some identifier cannot be matched to a device + Given that the device cannot be identified from the access token + And the request body property "$.device" is compliant with the request body schema but does not identify a valid device + When the request "createProvisioning" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "DEVICE_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + + # Errors 409 + + @qod_provisioning_createProvisioning_409.1_provisioning_conflict + Scenario: Provisioning conflict + Given a valid testing device supported by the service, identified by the token or provided in the request body + And a QoD provisioning already exists for that device + When the request "createProvisioning" is sent + 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 409 + And the response property "$.code" is "CONFLICT" + And the response property "$.message" contains a user friendly text + + # Errors 422 + + @qod_provisioning_createProvisioning_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 "createProvisioning" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_DEVICE_IDENTIFIERS" + And the response property "$.message" contains a user friendly text + + # This scenario is under discussion + @qod_provisioning_createProvisioning_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 "createProvisioning" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_IDENTIFIERS_MISMATCH" + And the response property "$.message" contains a user friendly text + + @qod_provisioning_createProvisioning_422.3_device_not_supported + Scenario: Service not available for the device + Given that service is not supported for all devices commercialized by the operator + And the service is not applicable for the device identified by the token or provided in the request body + When the request "createProvisioning" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user friendly text + + # TBD if we neeed a dedicated code + @quality-on-demand_createSession_422.4_qos_profile_incompatible_device + Scenario: QoS profile is not suitable for the device + Given that implementation has QoS Profiles restricted to certain devices + And the request body property "qosProfile" is set to a restricted QoS Profile + And a device not suitable for the restricted QoS Profiles is provided in the request body or identified by the access token + When the request "createProvisioning" 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 422 + And the response property "$.code" is "DEVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user friendly text + + # Typically with a 2-legged access token + @qod_provisioning_createProvisioning_422.5_unidentifiable_device + Scenario: Device not included and cannot be deducted from the access token + Given the header "Authorization" is set to a valid access which does not identifiy a single device + And the request body property "$.device" is not included + When the request "createProvisioning" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNIDENTIFIABLE_DEVICE" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature new file mode 100644 index 0000000000..536a7878e7 --- /dev/null +++ b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature @@ -0,0 +1,165 @@ +Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation deleteProvisioning + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # + # Testing assets: + # * The ProvisioningInfo of an existing QoD Provisiong + # * The ProvisioningInfo of an existing QoD Provisiong with status "AVAILABLE", and with provided values for "sink" and "sinkCredential" + # + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + + Background: Common deleteProvisioning setup + Given an environment at "apiRoot" + And the resource "/qod-provisioning/v0.1rc1/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 + And the path parameter "provisoningId" is set by default to an existing QoD provisioning ID + + # Success scenarios + + @qod_provisioning_deleteProvisioning_01_delete_existing_qod_provisioning_sync + Scenario: Delete an existing QoD Provisioning synchronously + Given that implementation deletes QoD provisioning synchronously + And an existing QoD provisioning created by operation createProvisioning + And the path parameter "provisoningId" is set to the value for that QoD provisioning + When the request "deleteProvisioning" is sent + Then the response status code is 204 + And the response header "x-correlator" has same value as the request header "x-correlator" + + @qod_provisioning_deleteProvisioning_02_delete_existing_qod_provisioning_async + Scenario: Delete an existing QoD Provisioning asynchronously + Given that implementation deletes QoD provisioning asynchronously + And an existing QoD provisioning created by operation createProvisioning + And the path parameter "provisoningId" is set to the value for that QoD provisioning + When the request "deleteProvisioning" is sent + Then the response status code is 202 + And the response header "x-correlator" has same value as the request header "x-correlator" + And the response header "Content-Type" is "application/json" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/ProvisioningInfo" + # Additionally any success response has to comply with some constraints beyond the schema compliance + And the response property "$.device" exists only if provided for createProvisioning and with the same value + And the response property "$.qosProfile" has the value provided for createProvisioning + And the response property "$.status" is "AVAILABLE" + And the response property "$.statusInfo" is "DELETE_REQUESTED" + And the response property "$.sink" exists only if provided for createProvisioning and with the same value + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatible for security concerns + And the response property "$.startedAt" exists and the value is in the past + + @qod_provisioning_deleteProvisioning_03_event_notification_sync + Scenario: Event is received if the provisioning was AVAILABLE and sink was provided (synchronous deletion) + Given that implementation deletes QoD provisioning synchronously + And an existing QoD provisioning created by operation createProvisioning with provided values for "sink" and "sinkCredential", and with status "AVAILABLE" + And the path parameter "provisoningId" is set to the value for that QoD provisioning + When the request "deleteProvisioning" is sent + Then the response status code is 204 + And an event is received at the address of the "$.sink" provided for createProvisioning + And the event header "Authorization" is set to "Bearer: " + the value of "$.sinkCredentials.accessToken" provided for createProvisioning + And the event header "Content-Type" is set to "application/cloudevents+json" + And the event body complies with the OAS schema at "/components/schemas/EventStatusChanged" + # Additionally any event body has to comply with some constraints beyond the schema compliance + And the event body property "$.id" is unique + And the event body property "$.type" is set to "org.camaraproject.qod-provisioning.v0.status-changed" + And the event body property "$.data.provisioningId" as returned for createProvisioning + And the event body property "$.data.status" is "UNAVAILABLE" + And the event body property "$.data.statusInfo" is "DELETE_REQUESTED" + + @qod_provisioning_deleteProvisioning_04_event_notification_async + Scenario: Event is received if the provisioning was AVAILABLE and sink was provided (asynchronous deletion) + Given that implementation deletes QoD provisioning asynchronously + And an existing QoD provisioning created by operation createProvisioning with provided values for "sink" and "sinkCredential", and with status "AVAILABLE" + And the path parameter "provisoningId" is set to the value for that QoD provisioning + When the request "deleteProvisioning" is sent + Then the response status code is 202 + When the asynchronous deletion process is completed + Then an event is received at the address of the "$.sink" provided for createProvisioning + And the event header "Authorization" is set to "Bearer: " + the value of "$.sinkCredentials.accessToken" provided for createProvisioning + And the event header "Content-Type" is set to "application/cloudevents+json" + And the event body complies with the OAS schema at "/components/schemas/EventStatusChanged" + # Additionally any event body has to comply with some constraints beyond the schema compliance + And the event body property "$.id" is unique + And the event body property "$.type" is set to "org.camaraproject.qod-provisioning.v0.status-changed" + And the event body property "$.data.provisioningId" as returned for createProvisioning + And the event body property "$.data.status" is "UNAVAILABLE" + And the event body property "$.data.statusInfo" is "DELETE_REQUESTED" + + # Errors 400 + + # 400 errors are not expected for this operation unless the implementation validates the format of provisioningId + # 404 NOT_FOUND is an alternative if path parameter format is not validated + @qod_provisioning_deleteProvisioning_400.1_invalid_id + Scenario: Invalid Argument. Generic Syntax Exception + Given the path parameter "provisioningId" has not a UUID format + When the request "deleteProvisioning" is sent + Then the response status code is 404 + 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 + + # Generic 401 errors + + @qod_provisioning_deleteProvisioning_401.1_no_authorization_header + Scenario: No Authorization header + Given the header "Authorization" is not sent + When the request "deleteProvisioning" 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" + 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 + @qod_provisioning_deleteProvisioning_401.2_expired_access_token + Scenario: Expired access token + Given the header "Authorization" is set to an expired access token + When the request "deleteProvisioning" 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 + + @qod_provisioning_deleteProvisioning_401.3_invalid_access_token + Scenario: Invalid access token + Given the header "Authorization" is set to an invalid access token + When the request "deleteProvisioning" 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" + And the response property "$.message" contains a user friendly text + + # Errors 403 + + @qod_provisioning_deleteProvisioning_403.1_different_client_id + Scenario: QoD provisioning not created by the API client given in the access token + # To test this, a token have to be obtained by a different client + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoD provisioning + When the request "deleteProvisioning" is sent + 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 403 + And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + @qod_provisioning_deleteProvisioning_404.1_not_found + Scenario: provisioningId of a no existing QoD provisioning + Given the path parameter "provisoningId" is set to a random UUID + When the request "deleteProvisioning" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "NOT_FOUND" + And the response property "$.message" contains a user friendly text + diff --git a/code/Test_definitions/qod-provisioning-getProvisioningById.feature b/code/Test_definitions/qod-provisioning-getProvisioningById.feature new file mode 100644 index 0000000000..c96fa71252 --- /dev/null +++ b/code/Test_definitions/qod-provisioning-getProvisioningById.feature @@ -0,0 +1,127 @@ +Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation getProvisioningById + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # + # Testing assets: + # * The provisioningId of an existing QoD Provisiong, and the request properties used for createProvisioning + # + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + + Background: Common getProvisioningById setup + Given an environment at "apiRoot" + And the resource "/qod-provisioning/v0.1rc1/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 + And the path parameter "provisoningId" is set by default to an existing QoD provisioning ID + + # Success scenarios + + @qod_provisioning_getProvisioningById_01_get_existing_qod_provisioning + Scenario: Get an existing QoD Provisioning by provisioningId + Given an existing QoD provisioning created by operation createProvisioning + And the path parameter "provisoningId" is set to the value for that QoD provisioning + When the request "getProvisioningById" is sent + Then the response status code is 200 + And the response header "x-correlator" has same value as the request header "x-correlator" + And the response header "Content-Type" is "application/json" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/ProvisioningInfo" + # Additionally any success response has to comply with some constraints beyond the schema compliance + And the response property "$.device" exists only if provided for createProvisioning and with the same value + And the response property "$.qosProfile" has the value provided for createProvisioning + And the response property "$.sink" exists only if provided for createProvisioning and with the same value + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatible for security concerns + And the response property "$.startedAt" exists only if "$.status" is not "REQUESTED" and the value is in the past + And the response property "$.statusInfo" exists only if "$.status" is "UNAVAILABLE" + + @qod_provisioning_getProvisioningById_02_get_recent_unvailable + Scenario: Provisioning becoming "UNAVAILABLE" is not released for at least 360 seconds + Given an existing QoD provisioning deleted in the last 360 seconds + And the path parameter "provisoningId" is set to the value for that QoD provisioning + When the request "getProvisioningById" is sent + Then the response status code is 200 + 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 body complies with the OAS schema at "/components/schemas/ProvisioningInfo" + And the response property "$.status" is "UNAVAILABLE" + + # Errors 400 + + # 400 errors are not expected for this operation unless the implementation validates the format of provisioningId + # 404 NOT_FOUND is an alternative if path parameter format is not validated + @qod_provisioning_getProvisioningById_400.1_invalid_id + Scenario: Invalid Argument. Generic Syntax Exception + Given the path parameter "provisioningId" has not a UUID format + When the request "getProvisioningById" 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 + + # Generic 401 errors + + @qod_provisioning_getProvisioningById_401.1_no_authorization_header + Scenario: No Authorization header + Given the header "Authorization" is not sent + When the request "getProvisioningById" 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" + 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 + @qod_provisioning_getProvisioningById_401.2_expired_access_token + Scenario: Expired access token + Given the header "Authorization" is set to an expired access token + When the request "getProvisioningById" 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 + + @qod_provisioning_getProvisioningById_401.3_invalid_access_token + Scenario: Invalid access token + Given the header "Authorization" is set to an invalid access token + When the request "getProvisioningById" 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" + And the response property "$.message" contains a user friendly text + + # Errors 403 + + @qod_provisioning_getProvisioningById_403.1_different_client_id + Scenario: QoD provisioning not created by the API client given in the access token + # To test this, a token have to be obtained by a different client + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoD provisioning + When the request "getProvisioningById" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + @qod_provisioning_getProvisioningById_404.1_not_found + Scenario: provisioningId of a no existing QoD provisioning + Given the path parameter "provisoningId" is set to a random UUID + When the request "getProvisioningById" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "NOT_FOUND" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature new file mode 100644 index 0000000000..262f45160c --- /dev/null +++ b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature @@ -0,0 +1,258 @@ +Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioningByDevice + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # * List of device identifier types which are not supported, among: phoneNumber, ipv4Address, ipv6Address. + # For this version, CAMARA does not allow the use of networkAccessIdentifier, so it is considered by default as not supported. + # + # Testing assets: + # * A device object with an existing QoD provisioning associated, and the request properties used for createProvisioning + # * A device object with NO existing QoD provisioning associated + # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any + # + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + + Background: Common retrieveProvisioningByDevice setup + Given an environment at "apiRoot" + And the resource "/qod-provisioning/v0.1rc1/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 + And the header "x-correlator" is set to a UUID value + + # Success scenarios + + @qod_provisioning_retrieveProvisioningByDevice_01_get_existing_qod_provisioning_by_device + Scenario: Get an existing QoD Provisioning by device + Given a valid testing device with an existing QoD Provisioning, identified by the token or provided in the request body + When the request "retrieveProvisioningByDevice" is sent + Then the response status code is 200 + And the response header "x-correlator" has same value as the request header "x-correlator" + And the response header "Content-Type" is "application/json" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/ProvisioningInfo" + # Additionally any success response has to comply with some constraints beyond the schema compliance + And the response property "$.device" exists only if provided for createProvisioning and with the same value + And the response property "$.qosProfile" has the value provided for createProvisioning + And the response property "$.sink" exists only if provided for createProvisioning and with the same value + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatible for security concerns + And the response property "$.startedAt" exists only if "$.status" is "AVAILABLE" and the value is in the past + And the response property "$.statusInfo" exists only if "$.status" is "UNAVAILABLE" + + # Errors 400 + + @qod_provisioning_retrieveProvisioningByDevice_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/RetrieveProvisioningByDevice" + When the request "retrieveProvisioningByDevice" is sent + 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 + + @qod_provisioning_retrieveProvisioningByDevice_400.2_no_request_body + Scenario: Missing request body + Given the request body is not included + When the request "retrieveProvisioningByDevice" 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 + + @qod_provisioning_retrieveProvisioningByDevice_400.3_empty_request_body + Scenario: Empty object as request body + Given the request body is set to {} + When the request "retrieveProvisioningByDevice" 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 + + @qod_provisioning_retrieveProvisioningByDevice_400.4_device_empty + Scenario Outline: The device value is an empty object + Given the request body property "$.device" is set to: {} + When the request "retrieveProvisioningByDevice" 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 + + @qod_provisioning_retrieveProvisioningByDevice_400.5_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 "" does not comply with the OAS schema at "" + When the request "retrieveProvisioningByDevice" 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 + + Examples: + | device_identifier | oas_spec_schema | + | $.device.phoneNumber | /components/schemas/PhoneNumber | + | $.device.ipv4Address | /components/schemas/NetworkAccessIdentifier | + | $.device.ipv6Address | /components/schemas/DeviceIpv4Addr | + | $.device.networkIdentifier | /components/schemas/DeviceIpv6Address | + + # The maximum is considered in the schema so a generic schema validator may fail and generate a 400 INVALID_ARGUMENT without further distinction, + # and both could be accepted + @qod_provisioning_retrieveProvisioningByDevice_400.6_out_of_range_port + Scenario: Out of range port + Given the request body property "$.device.ipv4Address.publicPort" is set to a value higher than 65535 + When the request "retrieveProvisioningByDevice" is sent + 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 "OUT_OF_RANGE" or "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + # Generic 401 errors + + @qod_provisioning_retrieveProvisioningByDevice_401.1_no_authorization_header + Scenario: No Authorization header + Given the header "Authorization" is not sent + When the request "retrieveProvisioningByDevice" 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" + 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 + @qod_provisioning_retrieveProvisioningByDevice_401.2_expired_access_token + Scenario: Expired access token + Given the header "Authorization" is set to an expired access token + When the request "retrieveProvisioningByDevice" 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 + + @qod_provisioning_retrieveProvisioningByDevice_401.3_invalid_access_token + Scenario: Invalid access token + Given the header "Authorization" is set to an invalid access token + When the request "retrieveProvisioningByDevice" 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" + And the response property "$.message" contains a user friendly text + + # Errors 403 + + @qod_provisioning_retrieveProvisioningByDevice_403.1_different_client_id + Scenario: QoD provisioning not created by the API client given in the access token + # To test this, a token have to be obtained for a different client + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoD provisioning + When the request "retrieveProvisioningByDevice" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.message" contains a user friendly text + + @qod_provisioning_retrieveProvisioningByDevice_403.2_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 "retrieveProvisioningByDevice" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "INVALID_TOKEN_CONTEXT" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + @qod_provisioning_retrieveProvisioningByDevice_404.1_not_found + Scenario: Device with no existing QoD provisioning + Given a valid testing device without an existing QoD Provisioning, identified by the token or provided in the request body + When the request "retrieveProvisioningByDevice" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "NOT_FOUND" + And the response property "$.message" contains a user friendly text + + # Typically with a 2-legged access token + @qod_provisioning_retrieveProvisioningByDevice_404.2_device_not_found + Scenario: Some identifier cannot be matched to a device + Given that the device cannot be identified from the access token + And the request body property "$.device" is compliant with the request body schema but does not identify a valid device + When the request "retrieveProvisioningByDevice" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "DEVICE_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + # Errors 422 + + @qod_provisioning_retrieveProvisioningByDevice_404.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 "retrieveProvisioningByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_DEVICE_IDENTIFIERS" + And the response property "$.message" contains a user friendly text + + # This scenario is under discussion + @qod_provisioning_retrieveProvisioningByDevice_404.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 "retrieveProvisioningByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_IDENTIFIERS_MISMATCH" + And the response property "$.message" contains a user friendly text + + @qod_provisioning_retrieveProvisioningByDevice_404.3_device_not_supported + Scenario: Service not available for the device + Given that service is not supported for all devices commercialized by the operator + And the service is not applicable for the device identified by the token or provided in the request body + When the request "retrieveProvisioningByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user friendly text + + # Typically with a 2-legged access token + @qod_provisioning_retrieveProvisioningByDevice_404.4_unidentifiable_device + Scenario: Device not included and cannot be deducted from the access token + Given the header "Authorization" is set to a valid access which does not identifiy a single device + And the request body property "$.device" is not included + When the request "retrieveProvisioningByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNIDENTIFIABLE_DEVICE" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/qos-profiles-getQosProfile.feature b/code/Test_definitions/qos-profiles-getQosProfile.feature new file mode 100644 index 0000000000..42daa7126b --- /dev/null +++ b/code/Test_definitions/qos-profiles-getQosProfile.feature @@ -0,0 +1,108 @@ +Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation getQosProfile + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # + # Testing assets: + # * The name of an existing QoS profile + # + # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0-rc.1 + + Background: Common getQosProfile setup + Given an environment at "apiRoot" + And the resource "qos-profiles/v0.11rc1/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 + + # Success scenarios + + @qos_profiles_getQosProfile_01_generic_success_scenario + Scenario: Common validations for any sucess scenario + # Valid testing device and default request body compliant with the schema + Given an existing QoS profile + And the path parameter "name" is set to the value for an that QoS profile + When the request "getQosProfile" 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 response property "$.name" value is equal to path param "name" + # TBC: Add additional constraints, such as max* properties must be higher than min* equivalent properties, etc + + # Errors 400 + + @qos_profiles_getQosProfile_400.1_name_does_not_match_regex + Scenario: Path parameter name doesn't match the defined regular expression + Given path parameter "name" does not match the regular expression "^[a-zA-Z0-9_.-]+$" + When the request "getQosProfile" 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_getQosProfile_400.2_invalid_name_length + Scenario: Path parameter name has an invalid length + Given path parameter "name" has a length not between 3 and 256 + When the request "getQosProfile" 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 + + # Generic 401 errors + + @qos_profiles_getQosProfile_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 "getQosProfile" 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" + 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_getQosProfile_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 "getQosProfile" 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_getQosProfile_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 "getQosProfile" 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" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + @qos_profiles_getQosProfile_404.1_not_found + Scenario: name of a no existing QoS profile + Given the path parameter "name" is set to a random string compliant with the pattern + When the request "getQosProfile" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "NOT_FOUND" + And the response property "$.message" contains a user friendly text \ No newline at end of file diff --git a/code/Test_definitions/qos-profiles-qosProfilesDevice.feature b/code/Test_definitions/qos-profiles-qosProfilesDevice.feature new file mode 100644 index 0000000000..58e9abf83d --- /dev/null +++ b/code/Test_definitions/qos-profiles-qosProfilesDevice.feature @@ -0,0 +1,224 @@ +Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # * List of device identifier types which are not supported, among: phoneNumber, ipv4Address, ipv6Address. + # For this version, CAMARA does not allow the use of networkAccessIdentifier, so it is considered by default as not supported. + # + # Testing assets: + # * The name of an existing QoS profile + # * If some QoS Profile is restricted for some devices, provide the QoS profile name and device + # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any + + + # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0-rc.1 + + Background: Common qosProfilesDevice setup + Given an environment at "apiRoot" + And the resource "qos-profiles/v0.11rc1/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 + # Properties not explicitly overwitten in the Scenarios can take any values compliant with the schema + And the request body is set by default to a request body compliant with the schema at "/components/schemas/QosProfileDeviceRequest" + + # Success scenarios + + @qos_profiles_qosProfilesDevice_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 + 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 + 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 + 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 + Scenario Outline: Retrieve QoS profiles only by status + Given the request body property "$.status" is set to the value + And the request body properties "$.device" and "$.name" are not included + When the request "qosProfilesDevice" 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" + And each item of the the response array, if any, has property "$[*].status" equal to + + Examples: + | status | + | ACTIVE | + | INACTIVE | + | DEPRECATED | + + @qos_profiles_qosProfilesDevice_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 + 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 + 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 + 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 + 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 + 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 body is [] + + + # Errors 400 + + @qos_profiles_qosProfilesDevice_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 + 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 + Scenario: Missing request body + Given the request body is not included + When the request "qosProfilesDevice" 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 + # 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 "" does not comply with the OAS schema at "" + When the request "qosProfilesDevice" 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 + + Examples: + | device_identifier | oas_spec_schema | + | $.device.phoneNumber | /components/schemas/PhoneNumber | + | $.device.ipv4Address | /components/schemas/NetworkAccessIdentifier | + | $.device.ipv6Address | /components/schemas/DeviceIpv4Addr | + | $.device.networkIdentifier | /components/schemas/DeviceIpv6Address | + + # Generic 401 errors + + @qos_profiles_qosProfilesDevice_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 + 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" + 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 + 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 + 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 + 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 + 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" + And the response property "$.message" contains a user friendly text + + + # Errors 403 + + @qos_profiles_qosProfilesDevice_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 + 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" + And the response property "$.status" is 403 + And the response property "$.code" is "INVALID_TOKEN_CONTEXT" + And the response property "$.message" contains a user friendly text + + # 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 + 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 + 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNPROCESSABLE_ENTITY" + And the response property "$.message" contains a user friendly text + + # This scenario is under discussion + @qos_profiles_qosProfilesDevice_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 + 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_IDENTIFIERS_MISMATCH" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/quality-on-demand-createSession.feature b/code/Test_definitions/quality-on-demand-createSession.feature new file mode 100644 index 0000000000..798475ea0d --- /dev/null +++ b/code/Test_definitions/quality-on-demand-createSession.feature @@ -0,0 +1,374 @@ +Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation createSession + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # * List of device identifier types which are not supported, among: phoneNumber, ipv4Address, ipv6Address. + # For this version, CAMARA does not allow the use of networkAccessIdentifier, so it is considered by default as not supported. + # * List of application server ip formats which are not supported, among ipv4 and ipv6. + # + # Testing assets: + # * A device object applicable for Quality On Demand service. + # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any. + # + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + + Background: Common createSession setup + Given an environment at "apiRoot" + And the resource "/quality-on-demand/v0.11rc1/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 + # Properties not explicitly overwitten in the Scenarios can take any values compliant with the schema + And the request body is set by default to a request body compliant with the schema at "/components/schemas/CreateSession" + + # Success scenarios + + @quality_on_demand_createSession_01_generic_success_scenario + Scenario: Common validations for any sucess scenario + # Valid testing device and default request body compliant with the schema + Given a valid testing device supported by the service, identified by the token or provided in the request body + And the request body property "$.applicationServer" is set to a valid application server + And the request property "$.qosProfile" is set to a valid QoS Profile as returned by QoS Profiles API + And the request body property "$.duration" is set to a valid duration for the selected QoS profile + When the request "createSession" is sent + Then the response status code is 201 + And the response header "Content-Type" is "application/json" + And the response header "x-correlator" has same value as the request header "x-correlator" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/SessionInfo" + # Additionally any success response has to comply with some constraints beyond the schema compliance + And the response property "$.device" exists only if provided in the request body and with the same value + And the response property "$.applicationServer" has the same value as in the request body + And the response property "$.qosProfile" has the same value as in the request body + And the response property "$.devicePorts" exists only if provided in the request body and with the same value + And the response property "$.applicationServerPorts" exists only if provided in the request body and with the same value + And the response property "$.sink" exists only if provided in the request body and with the same value + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatible for security concerns + And the response property "$.startedAt" exists only if "$.qosStatus" is "AVAILABLE" and the value is in the past + And the response property "$.expiresAt" exists only if "$.qosStatus" is not "REQUESTED" and the value is later than "$.startedAt" + And the response property "$.statusInfo" exists only if "$.qosStatus" is "UNAVAILABLE" + + @quality_on_demand_createSession_02_event_notification + Scenario: Events are received after a QoS session change if sink is provided + # Valid testing device and default request body compliant with the schema + Given a valid testing device supported by the service, identified by the token or provided in the request body + And the request body property "$.applicationServer" is set to a valid application server + And the request property "$.qosProfile" is set to a valid QoS Profile as returned by QoS Profiles API + And the request body property "$.duration" is set to a valid duration for the selected QoS profile + And the request property "$.sink" is set to a URL when events can be monitored + And the request property "$.sinkCredentials.credentialType" is set to "ACCESSTOKEN" + And the request property "$.sinkCredentials.accessTokenType" is set to "bearer" + And the request property "$.sinkCredentials.accessToken" is set to a valid access token accepted by the events receiver + When the request "createSession" is sent + Then the response status code is 201 + # There is no specific limit defined for the process to end + And an event is received at the address of the request property "$.sink" + And the event header "Authorization" is set to "Bearer: " + the value of the request property "$.sinkCredentials.accessToken" + And the event header "Content-Type" is set to "application/cloudevents+json" + And the event body complies with the OAS schema at "/components/schemas/EventQosStatusChanged" + # Additionally any event body has to comply with some constraints beyond the schema compliance + And the event body property "$.id" is unique + And the event body property "$.type" is set to "org.camaraproject.qod.v0.qos-status-changed" + And the event body property "$.data.sessionId" has the same value as createSession response property "$.sessionId" + And the event body property "$.data.qosStatus" is "AVAILABLE" or "UNAVAILABLE" + And the event body property "$.data.statusInfo" exists only if "$.data.qosStatus" is "UNAVAILABLE" + + @quality_on_demand_createSession_03_3_legged_missing_device + Scenario: Device is not returned if not included in the creation + # Valid testing device and default request body compliant with the schema + Given the header "Authorization" is set to a valid 3-legged access token associated to a valid testing device supported by the service + And the request property "$.device" is not included + When the request "createSession" is sent + Then the response status code is 201 + 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 body complies with the OAS schema at "/components/schemas/SessionInfo" + And the response property "$.device" does not exist + + # Errors 400 + + @quality_on_demand_createSession_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/CreateSession" + When the request "createSession" 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 + + + @quality_on_demand_createSession_400.2_no_request_body + Scenario: Missing request body + Given the request body is not included + When the request "createSession" 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 + + @quality_on_demand_createSession_400.3_empty_request_body + Scenario: Empty object as request body + Given the request body is set to {} + When the request "createSession" 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 + + @quality_on_demand_createSession_400.4_empty_property + Scenario Outline: Error response for empty property in request body + Given the request body property "" is set to {} + When the request "createSession" 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 + + Examples: + | required_property | + | $.device | + | $.applicationServer | + | $.devicePorts | + | $.applicationServerPorts | + | $.sinkCredential | + + @quality_on_demand_createSession_400.5_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 "" does not comply with the OAS schema at "" + When the request "createSession" 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 + + Examples: + | device_identifier | oas_spec_schema | + | $.device.phoneNumber | /components/schemas/PhoneNumber | + | $.device.ipv4Address | /components/schemas/NetworkAccessIdentifier | + | $.device.ipv6Address | /components/schemas/DeviceIpv4Addr | + | $.device.networkIdentifier | /components/schemas/DeviceIpv6Address | + + # The maximum is considered in the schema so a generic schema validator may fail and generate a 400 INVALID_ARGUMENT without further distinction, + # and both could be accepted + @quality_on_demand_createSession_400.6_out_of_range_port + Scenario Outline: Out of range port + Given the request body property "" is set to a value not between between 0 and 65536 + When the request "createSession" 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 "OUT_OF_RANGE" or "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + Examples: + | port_property | + | $.device.ipv4Address.publicPort | + | $.devicePorts.ranges.from | + | $.devicePorts.ranges.to | + | $.devicePorts.ports[*] | + | $.applicationServerPorts.ranges.from | + | $.applicationServerPorts.ranges.to | + | $.applicationServerPorts.ports[*] | + + # PLAIN and REFRESHTOKEN are considered in the schema so INVALID_ARGUMENT is not expected + @quality_on_demand_createSession_400.7_invalid_sink_credential + Scenario Outline: Invalid credential + Given the request body property "$.sinkCredential.credentialType" is set to "" + When the request "createSession" 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_CREDENTIAL" + And the response property "$.message" contains a user friendly text + + Examples: + | unsupported_credential_type | + | PLAIN | + | REFRESHTOKEN | + + # Only "bearer" is considered in the schema so a generic schema validator may fail and generate a 400 INVALID_ARGUMENT without further distinction, + # and both could be accepted + @quality_on_demand_createSession_400.8_sink_credential_invalid_token + Scenario: Invalid token + Given the request body property "$.sinkCredential.accessTokenType" is set to a value other than "bearer" + When the request "createSession" 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_TOKEN" or "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + @quality_on_demand_createSession_400.9_invalid_qos_profile + Scenario: Error response for invalid qos profile in request body + Given the request body property "qosProfile" is set to a non existent qos Profile + When the request "createSession" 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 + + @quality_on_demand_createSession_400.10_invalid_duration + Scenario: Error response when duration is not valid for selected qos profile + Given the request body property "duration" is set to an invalid duration for the selected qosProfile + When the request "createSession" 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 + + # Generic 401 errors + + @quality_on_demand_createSession_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 "createSession" 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" + 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 + @quality_on_demand_createSession_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 "createSession" 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 + + @quality_on_demand_createSession_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 "createSession" 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" + And the response property "$.message" contains a user friendly text + + + # Errors 403 + + @quality_on_demand_createSession_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 "createSession" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "INVALID_TOKEN_CONTEXT" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + # Typically with a 2-legged access token + @quality_on_demand_createSession_404.1_device_not_found + Scenario: Some identifier cannot be matched to a device + Given that the device cannot be identified from the access token + And the request body property "$.device" is compliant with the request body schema but does not identify a valid device + When the request "createSession" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "DEVICE_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + + # Errors 409 + + @quality_on_demand_createSession_409.1_session_conflict + Scenario: Session in conflict + Given a valid testing device supported by the service, identified by the token or provided in the request body + And a QoD session already exists for that device + When the request "createSession" 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 409 + And the response property "$.code" is "CONFLICT" + And the response property "$.message" contains a user friendly text + + # Errors 422 + + # UNSUPPORTED_DEVICE_IDENTIFIERS is in the Commonalities guidelines (document) but it is not yet considered in the API spec + @quality_on_demand_createSession_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 "createSession" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_DEVICE_IDENTIFIERS" + And the response property "$.message" contains a user friendly text + + # This scenario is under discussion + @quality_on_demand_createSession_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 "createSession" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_IDENTIFIERS_MISMATCH" + And the response property "$.message" contains a user friendly text + + @quality_on_demand_createSession_422.3_device_not_supported + Scenario: Service not available for the device + Given that service is not supported for all devices commercialized by the operator + And the service is not applicable for the device identified by the token or provided in the request body + When the request "createSession" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user friendly text + + # Typically with a 2-legged access token + @quality_on_demand_createSession_422.4_unidentifiable_device + Scenario: Device not included and cannot be deducted from the access token + Given the header "Authorization" is set to a valid access which does not identifiy a single device + And the request body property "$.device" is not included + When the request "createSession" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNIDENTIFIABLE_DEVICE" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/quality-on-demand-deleteSession.feature b/code/Test_definitions/quality-on-demand-deleteSession.feature new file mode 100644 index 0000000000..69a025df29 --- /dev/null +++ b/code/Test_definitions/quality-on-demand-deleteSession.feature @@ -0,0 +1,126 @@ +Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation deleteSession + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # + # Testing assets: + # * The sessionId of an existing session. + # * The sessionId of an existing session with status "AVAILABLE", and with provided values for "sink" and "sinkCredential". + # * The sessionId of an existing session with status "UNAVAILABLE", and with provided values for "sink" and "sinkCredential". + # + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + + Background: Common deleteSession setup + Given an environment at "apiRoot" + And the resource "/quality_on_demand/v0.11rc1/sessions/{sessionId}" + # 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 + And the header "x-correlator" is set to a UUID value + And the path parameter "sessionId" is set by default to a existing QoS session sessionId + + # Success scenarios + + @quality_on_demand_deleteSession_01_delete_existing_qod_session + Scenario: Delete an existing QoD session + Given an existing QoS session created by operation createSession + And the path parameter "sessionId" is set to the value for that QoS session + When the request "deleteSession" is sent + Then the response status code is 204 + And the response header "Content-Type" is "application/json" + And the response header "x-correlator" has same value as the request header "x-correlator" + + @quality_on_demand_deleteSession_02_event_notification + Scenario: Event is received if the session was AVAILABLE and sink was provided + Given an existing QoS session created by operation createProvisioning with provided values for "sink" and "sinkCredential", and with status "AVAILABLE" + And the path parameter "sessionId" is set to the value for that QoS session + When the request "deleteSession" is sent + Then the response status code is 204 + And an event is received at the address of the "$.sink" provided for createSession + And the event header "Authorization" is set to "Bearer: " + the value of the property "$.sinkCredentials.accessToken" provided for createSession + And the event header "Content-Type" is set to "application/cloudevents+json" + And the event body complies with the OAS schema at "/components/schemas/EventQosStatusChanged" + # Additionally any event body has to comply with some constraints beyond the schema compliance + And the event body property "$.id" is unique + And the event body property "$.type" is set to "org.camaraproject.qod.v0.qos-status-changed" + And the event body property "$.data.sessionId" as returned for createProvisioning + And the event body property "$.data.qosStatus" is "UNAVAILABLE" + And the event body property "$.data.statusInfo" is "DELETE_REQUESTED" + + # Errors 400 + + # 400 errors are not expected for this operation unless the implementation validates the format of sessionId + # 404 NOT_FOUND is an alternative if path parameter format is not validated + @quality_on_demand_deleteSession_400.1_invalid_session_id + Scenario: Invalid Argument. Generic Syntax Exception + Given the path parameter "sessionId" has not a UUID format + When the request "deleteSession" 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 + + # Generic 401 errors + + @quality_on_demand_deleteSession_401.1_no_authorization_header + Scenario: Error response for no header "Authorization" + Given the header "Authorization" is not sent + When the request "deleteSession" 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" + 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 + @quality_on_demand_deleteSession_401.2_expired_access_token + Scenario: Error response for expired access token + Given the header "Authorization" is set to an expired access token + When the request "deleteSession" 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 + + @quality_on_demand_deleteSession_401.3_invalid_access_token + Scenario: Error response for invalid access token + Given the header "Authorization" is set to an invalid access token + When the request "deleteSession" 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" + And the response property "$.message" contains a user friendly text + + + # Errors 403 + + @quality_on_demand_deleteSession_403.1_session_token_mismatch + Scenario: QoS session not created by the API client given in the access token + # To test this, a token have to be obtained for a different client + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session And the header "Authorization" is set to a valid access token emitted for a different device + When the request "deleteSession" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + @quality_on_demand_deleteSession_404.1_not_found + Scenario: sessionId of a no existing QoS session + Given the path parameter "sessionId" is set to a random UUID + When the request "deleteSession" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "NOT_FOUND" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature new file mode 100644 index 0000000000..c3fa1978aa --- /dev/null +++ b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature @@ -0,0 +1,194 @@ +Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation extendQosSessionDuration + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # + # Testing assets: + # * The sessionId of an existing session with qosStatus "AVAILABLE" + # * The sessionId of an existing session with qosStatus "UNAVAILABLE" + # + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + + Background: Common extendQosSessionDuration setup + Given an environment at "apiRoot" + And the resource "/quality-on-demand/v0.11rc1/sessions/{sessionId}/extend" + 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 + # Properties not explicitly overwitten in the Scenarios can take any values compliant with the schema + And the request body is set by default to a request body compliant with the schema at "/components/schemas/ExtendSessionDuration" + And the path parameter "sessionId" is set by default to a existing QoS session sessionId + + # Success scenarios + + @quality_on_demand_extendQosSessionDuration_01_generic_success_scenario + Scenario: Common validations for any sucess scenario + # Valid testing device and default request body compliant with the schema + Given an existing QoS session created by operation createSession with qosStatus "AVAILABLE" + And the path parameter "sessionId" is set to the value for that QoS session + And the request body property "$.requestedAdditionalDuration" is set to a valid additional session duration + When the request "extendQosSessionDuration" 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" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/SessionInfo" + And the response property "$.device" exists only if provided for createSession and with the same value + And the response property "$.applicationServer" has the same value as in the request body + And the response property "$.qosProfile" has the value provided for createSession + And the response property "$.devicePorts" exists only if provided for createSession and with the same value + And the response property "$.applicationServerPorts" exists only if provided for createSession and with the same value + And the response property "$.sink" exists only if provided for createSession and with the same value + # Implementations may not grant the requested extensions but they duration can not be reduced in any case + And the response property "$.duration" is not lower than request property "$.requestedAdditionalDuration" + + @quality_on_demand_extendQosSessionDuration_02_exceed_max_duration + Scenario: Extended duration cannot exceed the maxDuration for the QoS profile + # Valid testing device and default request body compliant with the schema + Given an existing QoS session created by operation createSession with qosStatus "AVAILABLE" + And the path parameter "sessionId" is set to the value for that QoS session + And the "maxDuration" for the QoS profile of the session as returned by "qos-profiles" API + And the request body property "$.requestedAdditionalDuration" is set to a value that added to the existing QoS session "duration" exceeds the "maxDuration" for the QoS Profile + When the request "extendQosSessionDuration" 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" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/SessionInfo" + And the response property "$.duration" does not exceed the "maxDuration" for the QoS Profile + + # To be discussed. Behaviour when the qosStatus of the session is REQUESTED + @quality_on_demand_extendQosSessionDuration_03_requestedSession + Scenario: Response extending duration for unavailable session + Given an existing QoS session created by operation createSession with qosStatus "REQUESTED" + And the path parameter "sessionId" is set to the value for that QoS session + And the request body is set to a valid request body + When the request "extendQosSessionDuration" is sent + Then the response status code is TBD + And the response header "x-correlator" has same value as the request header "x-correlator" + And the response header "Content-Type" is "application/json" + + # To be discussed. Behaviour when the qosStatus of the session is UNAVAILABLE + @quality_on_demand_extendQosSessionDuration_04_unavailableSession + Scenario: Response extending duration for unavailable session + Given an existing QoS session created by operation createSession with qosStatus "UNAVAILABLE" + And the path parameter "sessionId" is set to the value for that QoS session + And the request body is set to a valid request body + When the request "extendQosSessionDuration" is sent + Then the response status code is TBD + And the response header "x-correlator" has same value as the request header "x-correlator" + And the response header "Content-Type" is "application/json" + + # Errors 400 + + @quality_on_demand_extendQosSessionDuration_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/extendQosSessionDuration" + When the request "extendQosSessionDuration" 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 + + # 404 NOT_FOUND is an alternative if path parameter format is not validated + @quality_on_demand_extendQosSessionDuration_400.2_invalid_session_id + Scenario: Invalid Argument. Generic Syntax Exception + Given the path parameter "sessionId" has not a UUID format + When the request "extendQosSessionDuration" 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 + + @quality_on_demand_extendQosSessionDuration_400.3_no_request_body + Scenario: Missing request body + Given the request body is not included + When the request "extendQosSessionDuration" 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 + + @quality_on_demand_extendQosSessionDuration_400.4_empty_request_body + Scenario: Empty object as request body + Given the request body is set to {} + When the request "extendQosSessionDuration" 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 + + # Generic 401 errors + + @quality_on_demand_extendQosSessionDuration_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 "extendQosSessionDuration" 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" + 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 + @quality_on_demand_extendQosSessionDuration_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 "extendQosSessionDuration" 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 + + @quality_on_demand_extendQosSessionDuration_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 "extendQosSessionDuration" 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" + And the response property "$.message" contains a user friendly text + + + # Errors 403 + + @quality_on_demand_extendQosSessionDuration_403.1_session_token_mismatch + Scenario: QoS session not created by the API client given in the access token + # To test this, a token have to be obtained for a different client + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session And the header "Authorization" is set to a valid access token emitted for a different device + When the request "extendQosSessionDuration" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + @quality_on_demand_extendQosSessionDuration_404.1_not_found + Scenario: sessionId of a no existing QoS session + Given the path parameter "sessionId" is set to a random UUID + And the request body is set to a valid request body + When the request "extendQosSessionDuration" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "NOT_FOUND" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/quality-on-demand-getSession.feature b/code/Test_definitions/quality-on-demand-getSession.feature new file mode 100644 index 0000000000..1b1621df5a --- /dev/null +++ b/code/Test_definitions/quality-on-demand-getSession.feature @@ -0,0 +1,133 @@ +Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation getSession + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # + # Testing assets: + # * The sessionId of an existing QoS session, and the request properties used for createSession + # + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + + Background: Common getSession setup + Given an environment at "apiRoot" + And the resource "/quality-on-demand/v0.11rc1/sessions/{sessionId}" + # Unless indicated otherwise the session must be created by the same API client given in the access token + 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 parameter "sessionId" is set by default to a existing QoS session sessionId + + # Success scenarios + + @quality_on_demand_getSession_01_get_existing_session + Scenario: Get an existing QoD session by sessionId + Given an existing QoS session created by operation createSession + And the path parameter "sessionId" is set to the value for that QoS session + When the request "getSession" 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" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/SessionInfo" + # Additionally any success response has to comply with some constraints beyond the schema compliance + And the response property "$.device" exists only if provided for createSession and with the same value + And the response property "$.applicationServer" has the same value as in the request body + And the response property "$.qosProfile" has the value provided for createSession + And the response property "$.devicePorts" exists only if provided for createSession and with the same value + And the response property "$.applicationServerPorts" exists only if provided for createSession and with the same value + And the response property "$.sink" exists only if provided for createSession and with the same value + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatible for security concerns + And the response property "$.startedAt" exists only if "$.qosStatus" is "AVAILABLE" and the value is in the past + And the response property "$.expiresAt" exists only if "$.qosStatus" is not "REQUESTED" and the value is later than "$.startedAt" + And the response property "$.statusInfo" exists only if "$.qosStatus" is "UNAVAILABLE" + + @quality_on_demand_getSession_02_get_recent_unvailable + Scenario: QOS Session becoming "UNAVAILABLE" is not released for at least 360 seconds + Given an existing QoS session deleted in the last 360 seconds + And the path parameter "sessionId" is set to the value for that QoS session + When the request "getSession" 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 body complies with the OAS schema at "/components/schemas/SessionInfo" + And the response property "$.status" is "UNAVAILABLE" + + # Errors 400 + + # 400 errors are not expected for this operation unless the implementation validates the format of sessionId + # 404 NOT_FOUND is an alternative if path parameter format is not validated + @quality_on_demand_getSession_400.1_invalid_session_id + Scenario: Invalid Argument. Generic Syntax Exception + Given the path parameter "sessionId" has not a UUID format + When the request "getSession" 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 + + # Generic 401 errors + + @quality_on_demand_getSession_401.1_no_authorization_header + Scenario: Error response for no header "Authorization" + Given the header "Authorization" is not sent + When the request "getSession" 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" + 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 + @quality_on_demand_getSession_401.2_expired_access_token + Scenario: Error response for expired access token + Given the header "Authorization" is set to an expired access token + When the request "getSession" 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 + + @quality_on_demand_getSession_401.3_invalid_access_token + Scenario: Error response for invalid access token + Given the header "Authorization" is set to an invalid access token + When the request "getSession" 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" + And the response property "$.message" contains a user friendly text + + + # Errors 403 + + @quality_on_demand_getSession_403.1_session_token_mismatch + Scenario: QoS session not created by the API client given in the access token + # To test this, a token have to be obtained for a different client + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session + And the header "Authorization" is set to a valid access token emitted for a different device + When the request "getSession" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + @quality_on_demand_getSession_404.1_not_found + Scenario: sessionId of a no existing QoS session + Given the path parameter "sessionId" is set to a random UUID + When the request "getSession" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "NOT_FOUND" + And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature new file mode 100644 index 0000000000..76c329c546 --- /dev/null +++ b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature @@ -0,0 +1,259 @@ +Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation retrieveSessionsByDevice + # Input to be provided by the implementation to the tester + # + # Implementation indications: + # * apiRoot: API root of the server URL + # * List of device identifier types which are not supported, among: phoneNumber, ipv4Address, ipv6Address. + # For this version, CAMARA does not allow the use of networkAccessIdentifier, so it is considered by default as not supported. + # + # Testing assets: + # * A device object applicable for Quality On Demand service with an QoS Sessions associated, and the request properties used for createSession + # * A device object applicable for Quality On Demand service with NO QoS Sessions associated + # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any. + # + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + + Background: Common retrieveSessionsByDevice setup + Given an environment at "apiRoot" + And the resource "/quality-on-demand/v0.11rc1/retrieve-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 + # Properties not explicitly overwitten in the Scenarios can take any values compliant with the schema + And the request body is set by default to a request body compliant with the schema at "/components/schemas/RetrieveSessionsInput" + + # Success scenarios + + @quality_on_demand_retrieveSessionsByDevice_01_get_existing_session_by_device + Scenario: Get an existing QoD session by device + Given a valid testing device supported by the service, identified by the token or provided in the request body, with QoS active sessions associated + When the request "retrieveSessionsByDevice" 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" + # The response has to comply with the generic response schema which is part of the spec + And the response body complies with the OAS schema at "/components/schemas/RetrieveSessionsOutput" + # Additionally any success response has to comply with some constraints beyond the schema compliance + And the response property "$.device" exists only if provided for createSession and with the same value + And the response property "$.applicationServer" has the same value as in the request body + And the response property "$.qosProfile" has the value provided for createSession + And the response property "$.devicePorts" exists only if provided for createSession and with the same value + And the response property "$.applicationServerPorts" exists only if provided for createSession and with the same value + And the response property "$.sink" exists only if provided for createSession and with the same value + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatible for security concerns + And the response property "$.startedAt" exists only if "$.qosStatus" is "AVAILABLE" and the value is in the past + And the response property "$.expiresAt" exists only if "$.qosStatus" is not "REQUESTED" and the value is later than "$.startedAt" + And the response property "$.statusInfo" exists only if "$.qosStatus" is "UNAVAILABLE" + + @quality_on_demand_retrieveSessionsByDevice_02_sessions_not_found + Scenario: Device has not QoS sessions + # Valid testing device and default request body compliant with the schema + Given a valid testing device supported by the service, identified by the token or provided in the request body with no QoS active sessions associated + When the request "retrieveSessionsByDevice" 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 body is [] + + + # Errors 400 + + @quality_on_demand_retrieveSessionsByDevice_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/retrieveSessionsByDevice" + When the request "retrieveSessionsByDevice" 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 + + + @quality_on_demand_retrieveSessionsByDevice_400.2_no_request_body + Scenario: Missing request body + Given the request body is not included + When the request "retrieveSessionsByDevice" 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 + + @quality_on_demand_retrieveSessionsByDevice_400.3_empty_request_body + Scenario: Empty object as request body + Given the request body is set to {} + When the request "retrieveSessionsByDevice" 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 + + @quality_on_demand_retrieveSessionsByDevice_400.4_empty_device + Scenario: Error response for empty device in request body + Given the request body property "$.device" is set to {} + When the request "retrieveSessionsByDevice" 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 + + @quality_on_demand_retrieveSessionsByDevice_400.5_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 "" does not comply with the OAS schema at "" + When the request "retrieveSessionsByDevice" 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 + + Examples: + | device_identifier | oas_spec_schema | + | $.device.phoneNumber | /components/schemas/PhoneNumber | + | $.device.ipv4Address | /components/schemas/NetworkAccessIdentifier | + | $.device.ipv6Address | /components/schemas/DeviceIpv4Addr | + | $.device.networkIdentifier | /components/schemas/DeviceIpv6Address | + + # The maximum is considered in the schema so a generic schema validator may fail and generate a 400 INVALID_ARGUMENT without further distinction, + # and both could be accepted + @quality_on_demand_retrieveSessionsByDevice_400.6_out_of_range_port + Scenario: Out of range port + Given the request body property "$.device.ipv4Address.publicPort" is set to a value not between between 0 and 65536 + When the request "retrieveSessionsByDevice" 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 "OUT_OF_RANGE" or "INVALID_ARGUMENT" + And the response property "$.message" contains a user friendly text + + # Generic 401 errors + + @quality_on_demand_retrieveSessionsByDevice_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 "retrieveSessionsByDevice" 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" + 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 + @quality_on_demand_retrieveSessionsByDevice_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 "retrieveSessionsByDevice" 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 + + @quality_on_demand_retrieveSessionsByDevice_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 "retrieveSessionsByDevice" 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" + And the response property "$.message" contains a user friendly text + + + # Errors 403 + + @quality_on_demand_retrieveSessionsByDevice_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 "retrieveSessionsByDevice" 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" + And the response property "$.status" is 403 + And the response property "$.code" is "INVALID_TOKEN_CONTEXT" + And the response property "$.message" contains a user friendly text + + # Errors 404 + + # Typically with a 2-legged access token + @quality_on_demand_retrieveSessionsByDevice_404.1_device_not_found + Scenario: Some identifier cannot be matched to a device + Given that the device cannot be identified from the access token + And the request body property "$.device" is compliant with the request body schema but does not identify a valid device + When the request "retrieveSessionsByDevice" is sent + Then the response status code is 404 + 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 404 + And the response property "$.code" is "DEVICE_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + # Errors 422 + + # UNSUPPORTED_DEVICE_IDENTIFIERS is in the Commonalities guidelines (document) but it is not yet considered in the API spec + @quality_on_demand_retrieveSessionsByDevice_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 "retrieveSessionsByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNPROCESSABLE_ENTITY" + And the response property "$.message" contains a user friendly text + + # This scenario is under discussion + @quality_on_demand_retrieveSessionsByDevice_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 "retrieveSessionsByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_IDENTIFIERS_MISMATCH" + And the response property "$.message" contains a user friendly text + + @quality_on_demand_retrieveSessionsByDevice_422.3_device_not_supported + Scenario: Service not available for the device + Given that service is not supported for all devices commercialized by the operator + And the service is not applicable for the device identified by the token or provided in the request body + When the request "retrieveSessionsByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "DEVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user friendly text + + # Typically with a 2-legged access token + @quality_on_demand_retrieveSessionsByDevice_422.4_unidentifiable_device + Scenario: Device not included and cannot be deducted from the access token + Given the header "Authorization" is set to a valid access which does not identifiy a single device + And the request body property "$.device" is not included + When the request "retrieveSessionsByDevice" 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" + And the response property "$.status" is 422 + And the response property "$.code" is "UNIDENTIFIABLE_DEVICE" + And the response property "$.message" contains a user friendly text From 897366da289ffc1e29670cc1ef8ec5e04af278fc Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Wed, 28 Aug 2024 14:53:00 +0200 Subject: [PATCH 2/7] Types and fixes --- .../qod-provisioning-createProvisioning.feature | 6 +++--- .../qod-provisioning-deleteProvisioning.feature | 1 + ...-provisioning-retrieveProvisioningByDevice.feature | 11 ++++++----- .../quality-on-demand-createSession.feature | 6 +++--- 4 files changed, 13 insertions(+), 11 deletions(-) diff --git a/code/Test_definitions/qod-provisioning-createProvisioning.feature b/code/Test_definitions/qod-provisioning-createProvisioning.feature index 37f2d1bde6..ba76f9924b 100644 --- a/code/Test_definitions/qod-provisioning-createProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-createProvisioning.feature @@ -145,7 +145,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation createProvisioning # The maximum is considered in the schema so a generic schema validator may fail and generate a 400 INVALID_ARGUMENT without further distinction, and both could be accepted @qod_provisioning_createProvisioning_400.6_out_of_range_port Scenario: Out of range port - Given the request body property "$.device.ipv4Address.publicPort" is set to a value higher than 65535 + Given the request body property "$.device.ipv4Address.publicPort" is set to a value not between 0 and 65536 When the request "createProvisioning" is sent Then the response status code is 400 And the response header "x-correlator" has same value as the request header "x-correlator" @@ -186,7 +186,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation createProvisioning # TBD if we neeed a dedicated code - @quality-on-demand_createSession_400.9_non_existent_qos_profile + @qod_provisioning_createProvisioning_400.9_non_existent_qos_profile Scenario: Non existent QoS profile Given the request body property "qosProfile" is set to a non-existent QoS Profile When the request "createProvisioning" is sent @@ -317,7 +317,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation createProvisioning And the response property "$.message" contains a user friendly text # TBD if we neeed a dedicated code - @quality-on-demand_createSession_422.4_qos_profile_incompatible_device + @qod_provisioning_createProvisioning_422.4_qos_profile_incompatible_device Scenario: QoS profile is not suitable for the device Given that implementation has QoS Profiles restricted to certain devices And the request body property "qosProfile" is set to a restricted QoS Profile diff --git a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature index 536a7878e7..e7218d46ea 100644 --- a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature @@ -144,6 +144,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation deleteProvisioning # To test this, a token have to be obtained by a different client Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoD provisioning When the request "deleteProvisioning" 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" And the response property "$.status" is 403 diff --git a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature index 262f45160c..3f092f12b2 100644 --- a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature +++ b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature @@ -108,8 +108,9 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioni # and both could be accepted @qod_provisioning_retrieveProvisioningByDevice_400.6_out_of_range_port Scenario: Out of range port - Given the request body property "$.device.ipv4Address.publicPort" is set to a value higher than 65535 + Given the request body property "$.device.ipv4Address.publicPort" is set to a value not between 0 and 65536 When the request "retrieveProvisioningByDevice" 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 @@ -207,7 +208,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioni # Errors 422 - @qod_provisioning_retrieveProvisioningByDevice_404.1_device_identifiers_unsupported + @qod_provisioning_retrieveProvisioningByDevice_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 @@ -220,7 +221,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioni And the response property "$.message" contains a user friendly text # This scenario is under discussion - @qod_provisioning_retrieveProvisioningByDevice_404.2_device_identifiers_mismatch + @qod_provisioning_retrieveProvisioningByDevice_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 @@ -232,7 +233,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioni And the response property "$.code" is "DEVICE_IDENTIFIERS_MISMATCH" And the response property "$.message" contains a user friendly text - @qod_provisioning_retrieveProvisioningByDevice_404.3_device_not_supported + @qod_provisioning_retrieveProvisioningByDevice_422.3_device_not_supported Scenario: Service not available for the device Given that service is not supported for all devices commercialized by the operator And the service is not applicable for the device identified by the token or provided in the request body @@ -245,7 +246,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0-rc.1 - Operation retrieveProvisioni And the response property "$.message" contains a user friendly text # Typically with a 2-legged access token - @qod_provisioning_retrieveProvisioningByDevice_404.4_unidentifiable_device + @qod_provisioning_retrieveProvisioningByDevice_422.4_unidentifiable_device Scenario: Device not included and cannot be deducted from the access token Given the header "Authorization" is set to a valid access which does not identifiy a single device And the request body property "$.device" is not included diff --git a/code/Test_definitions/quality-on-demand-createSession.feature b/code/Test_definitions/quality-on-demand-createSession.feature index 798475ea0d..2ba1974e40 100644 --- 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.10.0-rc.1 - Operation createSession +Feature: CAMARA Quality On Demand API, v0.11.0-rc.1 - Operation createSession # Input to be provided by the implementation to the tester # # Implementation indications: @@ -213,7 +213,7 @@ Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation createSession And the response property "$.code" is "INVALID_TOKEN" or "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @quality_on_demand_createSession_400.9_invalid_qos_profile + @quality_on_demand_createSession_400.9_non_existent_qos_profile Scenario: Error response for invalid qos profile in request body Given the request body property "qosProfile" is set to a non existent qos Profile When the request "createSession" is sent @@ -313,7 +313,7 @@ Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation createSession Given a valid testing device supported by the service, identified by the token or provided in the request body And a QoD session already exists for that device When the request "createSession" is sent - Then the response status code is 401 + Then the response status code is 409 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 409 From c90a378923d4918e64f4667d2767922fccd6ae83 Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Thu, 29 Aug 2024 13:17:47 +0200 Subject: [PATCH 3/7] Updated versions and operationId to r1.2 --- ...od-provisioning-createProvisioning.feature | 4 +- ...od-provisioning-deleteProvisioning.feature | 4 +- ...d-provisioning-getProvisioningById.feature | 4 +- ...oning-retrieveProvisioningByDevice.feature | 4 +- .../qos-profiles-getQosProfile.feature | 4 +- ... qos-profiles-retrieveQoSProfiles.feature} | 66 +++++++++---------- .../quality-on-demand-createSession.feature | 4 +- .../quality-on-demand-deleteSession.feature | 4 +- ...on-demand-extendQosSessionDuration.feature | 4 +- .../quality-on-demand-getSession.feature | 4 +- ...on-demand-retrieveSessionsByDevice.feature | 4 +- 11 files changed, 53 insertions(+), 53 deletions(-) rename code/Test_definitions/{qos-profiles-qosProfilesDevice.feature => qos-profiles-retrieveQoSProfiles.feature} (85%) diff --git a/code/Test_definitions/qod-provisioning-createProvisioning.feature b/code/Test_definitions/qod-provisioning-createProvisioning.feature index ba76f9924b..04dc6b8d64 100644 --- 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 index e7218d46ea..5686a3361e 100644 --- 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 index c96fa71252..c93430d2a2 100644 --- 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 index 3f092f12b2..6c574c000f 100644 --- 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 index 42daa7126b..66d49ce9b8 100644 --- 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/code/Test_definitions/qos-profiles-qosProfilesDevice.feature b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature similarity index 85% rename from code/Test_definitions/qos-profiles-qosProfilesDevice.feature rename to code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature index 58e9abf83d..2161973772 100644 --- a/code/Test_definitions/qos-profiles-qosProfilesDevice.feature +++ b/code/Test_definitions/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 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,20 +100,20 @@ 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" @@ -121,11 +121,11 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice 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 "" does not comply with the OAS schema at "" - 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,11 +155,11 @@ 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" @@ -167,11 +167,11 @@ Feature: CAMARA QoS Profiles API, v0.10.0-rc.1 - Operation qosProfilesDevice 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 index 2ba1974e40..9798998abf 100644 --- 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 diff --git a/code/Test_definitions/quality-on-demand-deleteSession.feature b/code/Test_definitions/quality-on-demand-deleteSession.feature index 69a025df29..21893a3d44 100644 --- a/code/Test_definitions/quality-on-demand-deleteSession.feature +++ b/code/Test_definitions/quality-on-demand-deleteSession.feature @@ -1,4 +1,4 @@ -Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation deleteSession +Feature: CAMARA Quality On Demand API, v0.11.0 - Operation deleteSession # Input to be provided by the implementation to the tester # # Implementation indications: @@ -13,7 +13,7 @@ Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation deleteSession Background: Common deleteSession setup Given an environment at "apiRoot" - And the resource "/quality_on_demand/v0.11rc1/sessions/{sessionId}" + And the resource "/quality_on_demand/v0.11/sessions/{sessionId}" # 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 And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature index c3fa1978aa..0a251efbea 100644 --- a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature +++ b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature @@ -1,4 +1,4 @@ -Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation extendQosSessionDuration +Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDuration # Input to be provided by the implementation to the tester # # Implementation indications: @@ -12,7 +12,7 @@ Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation extendQosSession Background: Common extendQosSessionDuration setup Given an environment at "apiRoot" - And the resource "/quality-on-demand/v0.11rc1/sessions/{sessionId}/extend" + And the resource "/quality-on-demand/v0.11/sessions/{sessionId}/extend" 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/quality-on-demand-getSession.feature b/code/Test_definitions/quality-on-demand-getSession.feature index 1b1621df5a..002ec54ce3 100644 --- a/code/Test_definitions/quality-on-demand-getSession.feature +++ b/code/Test_definitions/quality-on-demand-getSession.feature @@ -1,4 +1,4 @@ -Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation getSession +Feature: CAMARA Quality On Demand API, v0.11.0 - Operation getSession # Input to be provided by the implementation to the tester # # Implementation indications: @@ -11,7 +11,7 @@ Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation getSession Background: Common getSession setup Given an environment at "apiRoot" - And the resource "/quality-on-demand/v0.11rc1/sessions/{sessionId}" + And the resource "/quality-on-demand/v0.11/sessions/{sessionId}" # Unless indicated otherwise the session must be created by the same API client given in the access token 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/quality-on-demand-retrieveSessionsByDevice.feature b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature index 76c329c546..38e86688c8 100644 --- a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature +++ b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature @@ -1,4 +1,4 @@ -Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation retrieveSessionsByDevice +Feature: CAMARA Quality On Demand API, v0.11.0 - Operation retrieveSessionsByDevice # Input to be provided by the implementation to the tester # # Implementation indications: @@ -15,7 +15,7 @@ Feature: CAMARA Quality On Demand API, v0.10.0-rc.1 - Operation retrieveSessions Background: Common retrieveSessionsByDevice setup Given an environment at "apiRoot" - And the resource "/quality-on-demand/v0.11rc1/retrieve-sessions" + And the resource "/quality-on-demand/v0.11/retrieve-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 From a144056946a8f9ad3f7eb3a53b7ed46fea07c7a3 Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Thu, 29 Aug 2024 15:52:42 +0200 Subject: [PATCH 4/7] Corrections after Herbert's feedback --- code/Test_definitions/README.md | 1 + .../qod-provisioning-createProvisioning.feature | 2 +- .../qod-provisioning-deleteProvisioning.feature | 5 +++-- .../qod-provisioning-getProvisioningById.feature | 5 +++-- .../qod-provisioning-retrieveProvisioningByDevice.feature | 5 +++-- code/Test_definitions/qos-profiles-getQosProfile.feature | 2 +- .../qos-profiles-retrieveQoSProfiles.feature | 2 +- .../quality-on-demand-createSession.feature | 2 +- .../quality-on-demand-deleteSession.feature | 5 +++-- .../quality-on-demand-extendQosSessionDuration.feature | 5 +++-- code/Test_definitions/quality-on-demand-getSession.feature | 6 +++--- .../quality-on-demand-retrieveSessionsByDevice.feature | 2 +- 12 files changed, 24 insertions(+), 18 deletions(-) diff --git a/code/Test_definitions/README.md b/code/Test_definitions/README.md index 20be4f6345..0df81c02d1 100644 --- a/code/Test_definitions/README.md +++ b/code/Test_definitions/README.md @@ -14,4 +14,5 @@ The test plan has to be enhanced and some scenarios still contains comments and * 422 UNSUPPORTED_DEVICE_IDENTIFIERS is in the Commonalities guidelines (document) but it is not yet in the artifact and it not yet considered in the quality-on-demand or qos-profiles API specs, but it is in qod-provisioning API spec * It is not defined the expected behavior when extending the duration of a session in qosStatus REQUESTED or UNAVAILABLE * For QoS Profile response validations, it is pending to check additional constraints, such as minDuration being less or equal than maxDuration, etc +* When accessing a session or provisioning created by a different client, both 403 INVALID_TOKEN_CONTEXT and the generic 403 PERMISSION_DENIED codes could make sense. diff --git a/code/Test_definitions/qod-provisioning-createProvisioning.feature b/code/Test_definitions/qod-provisioning-createProvisioning.feature index 04dc6b8d64..2415c9d6bf 100644 --- a/code/Test_definitions/qod-provisioning-createProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-createProvisioning.feature @@ -10,7 +10,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation createProvisioning # * A device object applicable for QoD provisioning service # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any # - # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0 Background: Common createProvisioning setup Given an environment at "apiRoot" diff --git a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature index 5686a3361e..0d2fccb129 100644 --- a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature @@ -8,7 +8,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation deleteProvisioning # * The ProvisioningInfo of an existing QoD Provisiong # * The ProvisioningInfo of an existing QoD Provisiong with status "AVAILABLE", and with provided values for "sink" and "sinkCredential" # - # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0 Background: Common deleteProvisioning setup Given an environment at "apiRoot" @@ -139,6 +139,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation deleteProvisioning # Errors 403 + # TBD which code is more appropriate for this scenario @qod_provisioning_deleteProvisioning_403.1_different_client_id Scenario: QoD provisioning not created by the API client given in the access token # To test this, a token have to be obtained by a different client @@ -148,7 +149,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation deleteProvisioning 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 403 - And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.code" is "PERMISSION_DENIED" or "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text # Errors 404 diff --git a/code/Test_definitions/qod-provisioning-getProvisioningById.feature b/code/Test_definitions/qod-provisioning-getProvisioningById.feature index c93430d2a2..09142ecbd8 100644 --- a/code/Test_definitions/qod-provisioning-getProvisioningById.feature +++ b/code/Test_definitions/qod-provisioning-getProvisioningById.feature @@ -7,7 +7,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation getProvisioningById # Testing assets: # * The provisioningId of an existing QoD Provisiong, and the request properties used for createProvisioning # - # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0 Background: Common getProvisioningById setup Given an environment at "apiRoot" @@ -101,6 +101,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation getProvisioningById # Errors 403 + # TBD which code is more appropriate for this scenario @qod_provisioning_getProvisioningById_403.1_different_client_id Scenario: QoD provisioning not created by the API client given in the access token # To test this, a token have to be obtained by a different client @@ -110,7 +111,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation getProvisioningById 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 403 - And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.code" is "PERMISSION_DENIED" or "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text # Errors 404 diff --git a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature index 6c574c000f..1c95d40d5c 100644 --- a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature +++ b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature @@ -11,7 +11,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation retrieveProvisioningByD # * A device object with NO existing QoD provisioning associated # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any # - # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0-rc.1 + # References to OAS spec schemas refer to schemas specified in qod-provisioning.yaml, version 0.1.0 Background: Common retrieveProvisioningByDevice setup Given an environment at "apiRoot" @@ -155,6 +155,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation retrieveProvisioningByD # Errors 403 + # TBD which code is more appropriate for this scenario @qod_provisioning_retrieveProvisioningByDevice_403.1_different_client_id Scenario: QoD provisioning not created by the API client given in the access token # To test this, a token have to be obtained for a different client @@ -164,7 +165,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation retrieveProvisioningByD 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 403 - And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.code" is "PERMISSION_DENIED" or "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text @qod_provisioning_retrieveProvisioningByDevice_403.2_device_token_mismatch diff --git a/code/Test_definitions/qos-profiles-getQosProfile.feature b/code/Test_definitions/qos-profiles-getQosProfile.feature index 66d49ce9b8..ef0268a7af 100644 --- a/code/Test_definitions/qos-profiles-getQosProfile.feature +++ b/code/Test_definitions/qos-profiles-getQosProfile.feature @@ -7,7 +7,7 @@ Feature: CAMARA QoS Profiles API, v0.11.0 - Operation getQosProfile # Testing assets: # * The name of an existing QoS profile # - # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0 Background: Common getQosProfile setup Given an environment at "apiRoot" diff --git a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature index 2161973772..8b7e2a9c2f 100644 --- a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature +++ b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature @@ -12,7 +12,7 @@ Feature: CAMARA QoS Profiles API, v0.11.0 - Operation retrieveQoSProfiles # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any - # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0 Background: Common retrieveQoSProfiles setup Given an environment at "apiRoot" diff --git a/code/Test_definitions/quality-on-demand-createSession.feature b/code/Test_definitions/quality-on-demand-createSession.feature index 9798998abf..5d6a38b1ce 100644 --- a/code/Test_definitions/quality-on-demand-createSession.feature +++ b/code/Test_definitions/quality-on-demand-createSession.feature @@ -11,7 +11,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation createSession # * A device object applicable for Quality On Demand service. # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any. # - # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0 Background: Common createSession setup Given an environment at "apiRoot" diff --git a/code/Test_definitions/quality-on-demand-deleteSession.feature b/code/Test_definitions/quality-on-demand-deleteSession.feature index 21893a3d44..e964e1b9d1 100644 --- a/code/Test_definitions/quality-on-demand-deleteSession.feature +++ b/code/Test_definitions/quality-on-demand-deleteSession.feature @@ -9,7 +9,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation deleteSession # * The sessionId of an existing session with status "AVAILABLE", and with provided values for "sink" and "sinkCredential". # * The sessionId of an existing session with status "UNAVAILABLE", and with provided values for "sink" and "sinkCredential". # - # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0 Background: Common deleteSession setup Given an environment at "apiRoot" @@ -100,6 +100,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation deleteSession # Errors 403 + # TBD which code is more appropriate for this scenario @quality_on_demand_deleteSession_403.1_session_token_mismatch Scenario: QoS session not created by the API client given in the access token # To test this, a token have to be obtained for a different client @@ -109,7 +110,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation deleteSession 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 403 - And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.code" is "PERMISSION_DENIED" or "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text # Errors 404 diff --git a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature index 0a251efbea..38b45f8559 100644 --- a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature +++ b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature @@ -8,7 +8,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat # * The sessionId of an existing session with qosStatus "AVAILABLE" # * The sessionId of an existing session with qosStatus "UNAVAILABLE" # - # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0 Background: Common extendQosSessionDuration setup Given an environment at "apiRoot" @@ -167,6 +167,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat # Errors 403 + # TBD which code is more appropriate for this scenario @quality_on_demand_extendQosSessionDuration_403.1_session_token_mismatch Scenario: QoS session not created by the API client given in the access token # To test this, a token have to be obtained for a different client @@ -176,7 +177,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat 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 403 - And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.code" is "PERMISSION_DENIED" or "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text # Errors 404 diff --git a/code/Test_definitions/quality-on-demand-getSession.feature b/code/Test_definitions/quality-on-demand-getSession.feature index 002ec54ce3..94d6f98639 100644 --- a/code/Test_definitions/quality-on-demand-getSession.feature +++ b/code/Test_definitions/quality-on-demand-getSession.feature @@ -7,7 +7,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation getSession # Testing assets: # * The sessionId of an existing QoS session, and the request properties used for createSession # - # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0 Background: Common getSession setup Given an environment at "apiRoot" @@ -106,17 +106,17 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation getSession # Errors 403 + # TBD which code is more appropriate for this scenario @quality_on_demand_getSession_403.1_session_token_mismatch Scenario: QoS session not created by the API client given in the access token # To test this, a token have to be obtained for a different client Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session - And the header "Authorization" is set to a valid access token emitted for a different device When the request "getSession" 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" And the response property "$.status" is 403 - And the response property "$.code" is "PERMISSION_DENIED" + And the response property "$.code" is "PERMISSION_DENIED" or "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text # Errors 404 diff --git a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature index 38e86688c8..b17ae50a36 100644 --- a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature +++ b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature @@ -11,7 +11,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation retrieveSessionsByDev # * A device object applicable for Quality On Demand service with NO QoS Sessions associated # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any. # - # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0 Background: Common retrieveSessionsByDevice setup Given an environment at "apiRoot" From 9146b15fb7d0ef89c90996157bb1315aa3e926db Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Fri, 30 Aug 2024 09:23:52 +0200 Subject: [PATCH 5/7] Correcting relevant linting issues Scenario Outline without examples, totally Step too long was really due to a previous step appended which had to be removed Repeated scenario names Multiple empty lines, not really wrong but same as trailing spaces The 2 When in an scenario is not really an error, but a common best practice. I have rephrase it a bit because for that specific scenario makes sense (first you delete and then when the async deletion is effective you received an event) --- .../qod-provisioning-createProvisioning.feature | 4 +--- .../qod-provisioning-deleteProvisioning.feature | 3 +-- .../qod-provisioning-retrieveProvisioningByDevice.feature | 2 +- .../qos-profiles-retrieveQoSProfiles.feature | 3 --- .../quality-on-demand-createSession.feature | 3 --- .../quality-on-demand-deleteSession.feature | 5 ++--- .../quality-on-demand-extendQosSessionDuration.feature | 7 +++---- code/Test_definitions/quality-on-demand-getSession.feature | 1 - .../quality-on-demand-retrieveSessionsByDevice.feature | 3 --- 9 files changed, 8 insertions(+), 23 deletions(-) diff --git a/code/Test_definitions/qod-provisioning-createProvisioning.feature b/code/Test_definitions/qod-provisioning-createProvisioning.feature index 2415c9d6bf..087066f486 100644 --- a/code/Test_definitions/qod-provisioning-createProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-createProvisioning.feature @@ -113,7 +113,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation createProvisioning And the response property "$.message" contains a user friendly text @qod_provisioning_createProvisioning_400.4_device_empty - Scenario Outline: The device value is an empty object + Scenario: The device value is an empty object Given the request body property "$.device" is set to: {} When the request "createProvisioning" is sent Then the response status code is 400 @@ -184,7 +184,6 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation createProvisioning And the response property "$.code" is "INVALID_TOKEN" or "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - # TBD if we neeed a dedicated code @qod_provisioning_createProvisioning_400.9_non_existent_qos_profile Scenario: Non existent QoS profile @@ -263,7 +262,6 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation createProvisioning And the response property "$.code" is "DEVICE_NOT_FOUND" And the response property "$.message" contains a user friendly text - # Errors 409 @qod_provisioning_createProvisioning_409.1_provisioning_conflict diff --git a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature index 0d2fccb129..b50cadb64f 100644 --- a/code/Test_definitions/qod-provisioning-deleteProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-deleteProvisioning.feature @@ -74,7 +74,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation deleteProvisioning And the path parameter "provisoningId" is set to the value for that QoD provisioning When the request "deleteProvisioning" is sent Then the response status code is 202 - When the asynchronous deletion process is completed + And when the asynchronous deletion process is completed Then an event is received at the address of the "$.sink" provided for createProvisioning And the event header "Authorization" is set to "Bearer: " + the value of "$.sinkCredentials.accessToken" provided for createProvisioning And the event header "Content-Type" is set to "application/cloudevents+json" @@ -164,4 +164,3 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation deleteProvisioning And the response property "$.status" is 404 And the response property "$.code" is "NOT_FOUND" And the response property "$.message" contains a user friendly text - diff --git a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature index 1c95d40d5c..66faf18899 100644 --- a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature +++ b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature @@ -75,7 +75,7 @@ Feature: CAMARA QoD Provisioning API, v0.1.0 - Operation retrieveProvisioningByD And the response property "$.message" contains a user friendly text @qod_provisioning_retrieveProvisioningByDevice_400.4_device_empty - Scenario Outline: The device value is an empty object + Scenario: The device value is an empty object Given the request body property "$.device" is set to: {} When the request "retrieveProvisioningByDevice" is sent Then the response status code is 400 diff --git a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature index 8b7e2a9c2f..b9ffd9ab12 100644 --- a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature +++ b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature @@ -11,7 +11,6 @@ Feature: CAMARA QoS Profiles API, v0.11.0 - Operation retrieveQoSProfiles # * If some QoS Profile is restricted for some devices, provide the QoS profile name and device # * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any - # References to OAS spec schemas refer to schemas specifies in qos-profiles.yaml, version 0.11.0 Background: Common retrieveQoSProfiles setup @@ -97,7 +96,6 @@ Feature: CAMARA QoS Profiles API, v0.11.0 - Operation retrieveQoSProfiles And the response header "x-correlator" has same value as the request header "x-correlator" And the response body is [] - # Errors 400 @qos_profiles_retrieveQoSProfiles_400.1_schema_not_compliant @@ -179,7 +177,6 @@ Feature: CAMARA QoS Profiles API, v0.11.0 - Operation retrieveQoSProfiles And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Errors 403 @qos_profiles_retrieveQoSProfiles_403.1_device_token_mismatch diff --git a/code/Test_definitions/quality-on-demand-createSession.feature b/code/Test_definitions/quality-on-demand-createSession.feature index 5d6a38b1ce..7f2ae3e148 100644 --- a/code/Test_definitions/quality-on-demand-createSession.feature +++ b/code/Test_definitions/quality-on-demand-createSession.feature @@ -99,7 +99,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation createSession And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @quality_on_demand_createSession_400.2_no_request_body Scenario: Missing request body Given the request body is not included @@ -274,7 +273,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation createSession And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Errors 403 @quality_on_demand_createSession_403.1_device_token_mismatch @@ -305,7 +303,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation createSession And the response property "$.code" is "DEVICE_NOT_FOUND" And the response property "$.message" contains a user friendly text - # Errors 409 @quality_on_demand_createSession_409.1_session_conflict diff --git a/code/Test_definitions/quality-on-demand-deleteSession.feature b/code/Test_definitions/quality-on-demand-deleteSession.feature index e964e1b9d1..cbbca9e106 100644 --- a/code/Test_definitions/quality-on-demand-deleteSession.feature +++ b/code/Test_definitions/quality-on-demand-deleteSession.feature @@ -9,7 +9,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation deleteSession # * The sessionId of an existing session with status "AVAILABLE", and with provided values for "sink" and "sinkCredential". # * The sessionId of an existing session with status "UNAVAILABLE", and with provided values for "sink" and "sinkCredential". # - # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0 + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 Background: Common deleteSession setup Given an environment at "apiRoot" @@ -97,14 +97,13 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation deleteSession And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Errors 403 # TBD which code is more appropriate for this scenario @quality_on_demand_deleteSession_403.1_session_token_mismatch Scenario: QoS session not created by the API client given in the access token # To test this, a token have to be obtained for a different client - Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session And the header "Authorization" is set to a valid access token emitted for a different device + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session When the request "deleteSession" is sent Then the response status code is 403 And the response header "x-correlator" has same value as the request header "x-correlator" diff --git a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature index 38b45f8559..c14f1b360c 100644 --- a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature +++ b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature @@ -60,7 +60,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat # To be discussed. Behaviour when the qosStatus of the session is REQUESTED @quality_on_demand_extendQosSessionDuration_03_requestedSession - Scenario: Response extending duration for unavailable session + Scenario: Response extending duration for requested session Given an existing QoS session created by operation createSession with qosStatus "REQUESTED" And the path parameter "sessionId" is set to the value for that QoS session And the request body is set to a valid request body @@ -94,7 +94,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat # 404 NOT_FOUND is an alternative if path parameter format is not validated @quality_on_demand_extendQosSessionDuration_400.2_invalid_session_id - Scenario: Invalid Argument. Generic Syntax Exception + Scenario: Invalid sessionId Given the path parameter "sessionId" has not a UUID format When the request "extendQosSessionDuration" is sent Then the response status code is 400 @@ -164,14 +164,13 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Errors 403 # TBD which code is more appropriate for this scenario @quality_on_demand_extendQosSessionDuration_403.1_session_token_mismatch Scenario: QoS session not created by the API client given in the access token # To test this, a token have to be obtained for a different client - Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session And the header "Authorization" is set to a valid access token emitted for a different device + Given the header "Authorization" is set to a valid access token emitted to a client which did not created the QoS session When the request "extendQosSessionDuration" is sent Then the response status code is 403 And the response header "x-correlator" has same value as the request header "x-correlator" diff --git a/code/Test_definitions/quality-on-demand-getSession.feature b/code/Test_definitions/quality-on-demand-getSession.feature index 94d6f98639..1a305242c7 100644 --- a/code/Test_definitions/quality-on-demand-getSession.feature +++ b/code/Test_definitions/quality-on-demand-getSession.feature @@ -103,7 +103,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation getSession And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Errors 403 # TBD which code is more appropriate for this scenario diff --git a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature index b17ae50a36..71b71927b0 100644 --- a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature +++ b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature @@ -55,7 +55,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation retrieveSessionsByDev And the response header "x-correlator" has same value as the request header "x-correlator" And the response body is [] - # Errors 400 @quality_on_demand_retrieveSessionsByDevice_400.1_schema_not_compliant @@ -69,7 +68,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation retrieveSessionsByDev And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @quality_on_demand_retrieveSessionsByDevice_400.2_no_request_body Scenario: Missing request body Given the request body is not included @@ -174,7 +172,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation retrieveSessionsByDev And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Errors 403 @quality_on_demand_retrieveSessionsByDevice_403.1_device_token_mismatch From 6c1e79883c82f797cc165abc738c3d2b0cd48558 Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Fri, 30 Aug 2024 10:47:26 +0200 Subject: [PATCH 6/7] Updated test for extending sessions not available --- code/Test_definitions/README.md | 1 - ...on-demand-extendQosSessionDuration.feature | 37 ++++++++----------- 2 files changed, 15 insertions(+), 23 deletions(-) diff --git a/code/Test_definitions/README.md b/code/Test_definitions/README.md index 0df81c02d1..01a2888348 100644 --- a/code/Test_definitions/README.md +++ b/code/Test_definitions/README.md @@ -12,7 +12,6 @@ The test plan has to be enhanced and some scenarios still contains comments and * Now that QoS Profiles may be restricted to certain devices, what code to return when the provided device in createSession is not suitable for the provided qosProfile. We may reuse 422 DEVICE_NOT_APPLICABLE * When providing a path parameter, such sessionId or provisioningId, which is not compliant with the spec format (UUID), what code to return? Options are 400 INVALID_ARGUMENT or 404 NOT_FOUND if path parameter format is not checked previously * 422 UNSUPPORTED_DEVICE_IDENTIFIERS is in the Commonalities guidelines (document) but it is not yet in the artifact and it not yet considered in the quality-on-demand or qos-profiles API specs, but it is in qod-provisioning API spec -* It is not defined the expected behavior when extending the duration of a session in qosStatus REQUESTED or UNAVAILABLE * For QoS Profile response validations, it is pending to check additional constraints, such as minDuration being less or equal than maxDuration, etc * When accessing a session or provisioning created by a different client, both 403 INVALID_TOKEN_CONTEXT and the generic 403 PERMISSION_DENIED codes could make sense. diff --git a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature index c14f1b360c..80ab9a1bba 100644 --- a/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature +++ b/code/Test_definitions/quality-on-demand-extendQosSessionDuration.feature @@ -58,28 +58,6 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat And the response body complies with the OAS schema at "/components/schemas/SessionInfo" And the response property "$.duration" does not exceed the "maxDuration" for the QoS Profile - # To be discussed. Behaviour when the qosStatus of the session is REQUESTED - @quality_on_demand_extendQosSessionDuration_03_requestedSession - Scenario: Response extending duration for requested session - Given an existing QoS session created by operation createSession with qosStatus "REQUESTED" - And the path parameter "sessionId" is set to the value for that QoS session - And the request body is set to a valid request body - When the request "extendQosSessionDuration" is sent - Then the response status code is TBD - And the response header "x-correlator" has same value as the request header "x-correlator" - And the response header "Content-Type" is "application/json" - - # To be discussed. Behaviour when the qosStatus of the session is UNAVAILABLE - @quality_on_demand_extendQosSessionDuration_04_unavailableSession - Scenario: Response extending duration for unavailable session - Given an existing QoS session created by operation createSession with qosStatus "UNAVAILABLE" - And the path parameter "sessionId" is set to the value for that QoS session - And the request body is set to a valid request body - When the request "extendQosSessionDuration" is sent - Then the response status code is TBD - And the response header "x-correlator" has same value as the request header "x-correlator" - And the response header "Content-Type" is "application/json" - # Errors 400 @quality_on_demand_extendQosSessionDuration_400.1_schema_not_compliant @@ -192,3 +170,18 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation extendQosSessionDurat And the response property "$.status" is 404 And the response property "$.code" is "NOT_FOUND" And the response property "$.message" contains a user friendly text + + # Errors 409 + + @quality_on_demand_extendQosSessionDuration_409.1_session_not_available + Scenario: Extending duration for session with qosStatus not available + Given an existing QoS session with qosStatus not "AVAILABLE" + And the path parameter "sessionId" is set to the value for that QoS session + And the request body is set to a valid request body + When the request "extendQosSessionDuration" is sent + Then the response status code is 409 + 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 409 + And the response property "$.code" is "QUALITY_ON_DEMAND.SESSION_EXTENSION_NOT_ALLOWED" + And the response property "$.message" contains a user friendly text From c33124ecb2364b789844252862ce2d317c0cd7cd Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Fri, 30 Aug 2024 10:49:31 +0200 Subject: [PATCH 7/7] Update code/Test_definitions/quality-on-demand-deleteSession.feature Co-authored-by: Herbert Damker --- code/Test_definitions/quality-on-demand-deleteSession.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/Test_definitions/quality-on-demand-deleteSession.feature b/code/Test_definitions/quality-on-demand-deleteSession.feature index cbbca9e106..b3fc26a1f1 100644 --- a/code/Test_definitions/quality-on-demand-deleteSession.feature +++ b/code/Test_definitions/quality-on-demand-deleteSession.feature @@ -9,7 +9,7 @@ Feature: CAMARA Quality On Demand API, v0.11.0 - Operation deleteSession # * The sessionId of an existing session with status "AVAILABLE", and with provided values for "sink" and "sinkCredential". # * The sessionId of an existing session with status "UNAVAILABLE", and with provided values for "sink" and "sinkCredential". # - # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0-rc.1 + # References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml, version 0.11.0 Background: Common deleteSession setup Given an environment at "apiRoot"