From b006514d391b0ee07ad4ceb7ed502181ab679855 Mon Sep 17 00:00:00 2001 From: Jose Luis Urien Date: Tue, 21 Jan 2025 18:05:57 +0100 Subject: [PATCH 1/8] Use common artifact for device test scenarios --- code/Test_definitions/README.md | 4 +- ...od-provisioning-createProvisioning.feature | 252 +++++++----------- ...oning-retrieveProvisioningByDevice.feature | 238 +++++++---------- .../qos-profiles-retrieveQoSProfiles.feature | 176 ++++++------ .../quality-on-demand-createSession.feature | 248 ++++++++--------- ...on-demand-retrieveSessionsByDevice.feature | 236 +++++++--------- 6 files changed, 507 insertions(+), 647 deletions(-) diff --git a/code/Test_definitions/README.md b/code/Test_definitions/README.md index 01a2888348..d7776ccf7b 100644 --- a/code/Test_definitions/README.md +++ b/code/Test_definitions/README.md @@ -8,10 +8,8 @@ The test plan has to be enhanced and some scenarios still contains comments and * 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 * 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 3cc6925029..b53a940942 100644 --- a/code/Test_definitions/qod-provisioning-createProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-createProvisioning.feature @@ -77,44 +77,113 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation createProvisioning And the response body complies with the OAS schema at "/components/schemas/ProvisioningInfo" And the response property "$.device" does not exist - # Errors 400 + # Common error scenarios for management of input parameter device - @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 + @qod_provisioning_createProvisioning_C01.01_device_empty + Scenario: The device value is an empty object + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is set to: {} + When the HTTP "POST" request 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 + + @qod_provisioning_createProvisioning_C01.02_device_identifiers_not_schema_compliant + Scenario Outline: Some device identifier value does not comply with the schema + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "" does not comply with the OAS schema at "" + When the HTTP "POST" request 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/DeviceIpv4Addr | + | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | + | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | - @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" + + # This scenario may happen e.g. with 2-legged access tokens, which do not identify a single device. + @qod_provisioning_createProvisioning_C01.03_device_not_found + Scenario: Some identifier cannot be matched to a device + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is compliant with the schema but does not identify a valid device + When the HTTP "POST" request is sent + Then the response status code is 404 + And the response property "$.status" is 404 + And the response property "$.code" is "IDENTIFIER_NOT_FOUND" And the response property "$.message" contains a user friendly text - @qod_provisioning_createProvisioning_400.4_device_empty - Scenario: The device value is an empty object - Given the request body property "$.device" is set to: {} + + @qod_provisioning_createProvisioning_C02.04_unnecessary_device + Scenario: Device not to be included when it can be deduced from the access token + Given the header "Authorization" is set to a valid access token identifying a device + And the request body property "$.device" is set to a valid device + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNNECESSARY_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @qod_provisioning_createProvisioning_C01.05_missing_device + Scenario: Device not included and cannot be deduced from the access token + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is not included + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "MISSING_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @qod_provisioning_createProvisioning_C01.06_unsupported_device + Scenario: None of the provided device identifiers is supported by the implementation + Given that some types of device identifiers are not supported by the implementation + And the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" only includes device identifiers not supported by the implementation + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + # When the service is only offered to certain types of devices or subscriptions, e.g. IoT, B2C, etc. + @qod_provisioning_createProvisioning_C01.07_device_not_supported + Scenario: Service not available for the device + Given that the service is not available for all devices commercialized by the operator + And a valid device, identified by the token or provided in the request body, for which the service is not applicable + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "SERVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user-friendly text + + + # Several identifiers provided but they do not identify the same device + # This scenario may happen with 2-legged access tokens, which do not identify a device + @qod_provisioning_createProvisioning_C01.08_device_identifiers_mismatch + Scenario: Device identifiers mismatch + Given the header "Authorization" is set to a valid access token which does not identify a single device + And at 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 HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "IDENTIFIER_MISMATCH" + And the response property "$.message" contains a user friendly text + + # 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" @@ -123,12 +192,9 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation createProvisioning 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 - # Note that device schema validation errors (if any) should be thrown even if a 3-legged access token is being used - 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 "" - And a 2-legged or 3-legged access token is being used + @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" @@ -137,23 +203,15 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation createProvisioning 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/DeviceIpv4Addr | - | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | - | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | - - # 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 not between 0 and 65535 + @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 "OUT_OF_RANGE" or "INVALID_ARGUMENT" + And the response property "$.code" is "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 @@ -246,21 +304,6 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation createProvisioning 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 - - # 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 "IDENTIFIER_NOT_FOUND" - And the response property "$.message" contains a user friendly text # Errors 409 @@ -274,96 +317,3 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation createProvisioning 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_IDENTIFIER" - 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 at 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 "IDENTIFIER_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 "SERVICE_NOT_APPLICABLE" - And the response property "$.message" contains a user friendly text - - # TBD if we neeed a dedicated code - @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 - 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 "SERVICE_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 deduced from the access token - Given the header "Authorization" is set to a valid access token which does not identifiy a 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 "MISSING_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @qod_provisioning_createProvisioning_422.6_device_token_mismatch - Scenario: Inconsistent access token context for the device - # To test this, a token has 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 obtained for a 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 "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @qod_provisioning_createProvisioning_422.7_unnecessary_device_identifier_in_request - Scenario: Explicit device identifier provided when device is identified by the access token - Given the request body property "$.device" is set to a valid testing device - And the header "Authorization" is set to a valid access token for that same 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 "UNNECESSARY_IDENTIFIER" - 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 b1caff08d7..a4b2d69e44 100644 --- a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature +++ b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature @@ -40,55 +40,124 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation retrieveProvisioningByDev 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 + # Common error scenarios for management of input parameter device - @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 + @qod_provisioning_retrieveProvisioningByDevice_C01.01_device_empty + Scenario: The device value is an empty object + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is set to: {} + When the HTTP "POST" request 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 + + @qod_provisioning_retrieveProvisioningByDevice_C01.02_device_identifiers_not_schema_compliant + Scenario Outline: Some device identifier value does not comply with the schema + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "" does not comply with the OAS schema at "" + When the HTTP "POST" request 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/DeviceIpv4Addr | + | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | + | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | - @qod_provisioning_retrieveProvisioningByDevice_400.4_device_empty - Scenario: The device value is an empty object - Given the request body property "$.device" is set to: {} + + # This scenario may happen e.g. with 2-legged access tokens, which do not identify a single device. + @qod_provisioning_retrieveProvisioningByDevice_C01.03_device_not_found + Scenario: Some identifier cannot be matched to a device + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is compliant with the schema but does not identify a valid device + When the HTTP "POST" request is sent + Then the response status code is 404 + And the response property "$.status" is 404 + And the response property "$.code" is "IDENTIFIER_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + + @qod_provisioning_retrieveProvisioningByDevice_C02.04_unnecessary_device + Scenario: Device not to be included when it can be deduced from the access token + Given the header "Authorization" is set to a valid access token identifying a device + And the request body property "$.device" is set to a valid device + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNNECESSARY_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @qod_provisioning_retrieveProvisioningByDevice_C01.05_missing_device + Scenario: Device not included and cannot be deduced from the access token + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is not included + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "MISSING_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @qod_provisioning_retrieveProvisioningByDevice_C01.06_unsupported_device + Scenario: None of the provided device identifiers is supported by the implementation + Given that some types of device identifiers are not supported by the implementation + And the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" only includes device identifiers not supported by the implementation + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + # When the service is only offered to certain types of devices or subscriptions, e.g. IoT, B2C, etc. + @qod_provisioning_retrieveProvisioningByDevice_C01.07_device_not_supported + Scenario: Service not available for the device + Given that the service is not available for all devices commercialized by the operator + And a valid device, identified by the token or provided in the request body, for which the service is not applicable + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "SERVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user-friendly text + + + # Several identifiers provided but they do not identify the same device + # This scenario may happen with 2-legged access tokens, which do not identify a device + @qod_provisioning_retrieveProvisioningByDevice_C01.08_device_identifiers_mismatch + Scenario: Device identifiers mismatch + Given the header "Authorization" is set to a valid access token which does not identify a single device + And at 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 HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "IDENTIFIER_MISMATCH" + And the response property "$.message" contains a user friendly text + + # 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 - 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 "" + @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" @@ -97,24 +166,15 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation retrieveProvisioningByDev 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 not between 0 and 65536 + @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 "OUT_OF_RANGE" or "INVALID_ARGUMENT" + And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text # Generic 401 errors @@ -190,95 +250,3 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation retrieveProvisioningByDev 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 "IDENTIFIER_NOT_FOUND" - And the response property "$.message" contains a user friendly text - - # Errors 422 - - @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 - 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_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # This scenario is under discussion - @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 - 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 "IDENTIFIER_MISMATCH" - And the response property "$.message" contains a user friendly text - - @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 - 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 "SERVICE_NOT_APPLICABLE" - And the response property "$.message" contains a user friendly text - - # Typically with a 2-legged access token - @qod_provisioning_retrieveProvisioningByDevice_422.4_unidentifiable_device - Scenario: Device not included and cannot be deduced from the access token - Given the header "Authorization" is set to a valid access token which does not identify a 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 "MISSING_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @qod_provisioning_retrieveProvisioningByDevice_422.5_device_token_mismatch - Scenario: Inconsistent access token context for the device - # To test this, a token has 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 obtained for a 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 "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @qod_provisioning_retrieveProvisioningByDevice_422.6_unnecessary_device_identifier_in_request - Scenario: Explicit device identifier provided when device is identified by the access token - Given the request body property "$.device" is set to a valid testing device - And the header "Authorization" is set to a valid access token for that same 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 "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text diff --git a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature index deea2e2800..79c4680467 100644 --- a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature +++ b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature @@ -96,6 +96,97 @@ Feature: CAMARA QoS Profiles API, vwip - Operation retrieveQoSProfiles And the response header "x-correlator" has same value as the request header "x-correlator" And the response body is [] + # Common error scenarios for management of input parameter device + + @qos_profiles_retrieveQoSProfiles_C01.01_device_empty + Scenario: The device value is an empty object + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is set to: {} + When the HTTP "POST" request is sent + Then the response status code is 400 + 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_retrieveQoSProfiles_C01.02_device_identifiers_not_schema_compliant + Scenario Outline: Some device identifier value does not comply with the schema + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "" does not comply with the OAS schema at "" + When the HTTP "POST" request is sent + Then the response status code is 400 + 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/DeviceIpv4Addr | + | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | + | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | + + + # This scenario may happen e.g. with 2-legged access tokens, which do not identify a single device. + @qos_profiles_retrieveQoSProfiles_C01.03_device_not_found + Scenario: Some identifier cannot be matched to a device + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is compliant with the schema but does not identify a valid device + When the HTTP "POST" request is sent + Then the response status code is 404 + And the response property "$.status" is 404 + And the response property "$.code" is "IDENTIFIER_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + + @qos_profiles_retrieveQoSProfiles_C02.04_unnecessary_device + Scenario: Device not to be included when it can be deduced from the access token + Given the header "Authorization" is set to a valid access token identifying a device + And the request body property "$.device" is set to a valid device + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNNECESSARY_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @qos_profiles_retrieveQoSProfiles_C01.06_unsupported_device + Scenario: None of the provided device identifiers is supported by the implementation + Given that some types of device identifiers are not supported by the implementation + And the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" only includes device identifiers not supported by the implementation + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + # When the service is only offered to certain types of devices or subscriptions, e.g. IoT, B2C, etc. + @qos_profiles_retrieveQoSProfiles_C01.07_device_not_supported + Scenario: Service not available for the device + Given that the service is not available for all devices commercialized by the operator + And a valid device, identified by the token or provided in the request body, for which the service is not applicable + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "SERVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user-friendly text + + + # Several identifiers provided but they do not identify the same device + # This scenario may happen with 2-legged access tokens, which do not identify a device + @qos_profiles_retrieveQoSProfiles_C01.08_device_identifiers_mismatch + Scenario: Device identifiers mismatch + Given the header "Authorization" is set to a valid access token which does not identify a single device + And at 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 HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "IDENTIFIER_MISMATCH" + And the response property "$.message" contains a user friendly text + # Errors 400 @qos_profiles_retrieveQoSProfiles_400.1_schema_not_compliant @@ -119,25 +210,6 @@ Feature: CAMARA QoS Profiles API, vwip - Operation retrieveQoSProfiles And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @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 "retrieveQoSProfiles" is sent - Then the response status code is 400 - And the response header "x-correlator" has same value as the request header "x-correlator" - And the response header "Content-Type" is "application/json" - And the response property "$.status" is 400 - And the response property "$.code" is "INVALID_ARGUMENT" - And the response property "$.message" contains a user friendly text - - Examples: - | device_identifier | oas_spec_schema | - | $.device.phoneNumber | /components/schemas/PhoneNumber | - | $.device.ipv4Address | /components/schemas/DeviceIpv4Addr | - | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | - | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | - # Generic 401 errors @qos_profiles_retrieveQoSProfiles_401.1_no_authorization_header @@ -190,69 +262,3 @@ Feature: CAMARA QoS Profiles API, vwip - Operation retrieveQoSProfiles And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - # Generic 422 errors - - @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 "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" - And the response property "$.status" is 422 - And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # This scenario is under discussion - @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 "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" - And the response property "$.status" is 422 - And the response property "$.code" is "IDENTIFIER_MISMATCH" - And the response property "$.message" contains a user friendly text - - # Typically with a 2-legged access token - @qod_provisioning_retrieveQoSProfiles_422.3_unidentifiable_device - Scenario: Device not included and cannot be deduced from the access token - Given the header "Authorization" is set to a valid access token that does not identify a device - And the request body property "$.device" is not included - 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" - And the response property "$.status" is 422 - And the response property "$.code" is "MISSING_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @qod_provisioning_retrieveQoSProfiles_422.4_device_token_mismatch - Scenario: Inconsistent access token context for the device - # To test this, a token has 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 obtained for a different device - 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" - And the response property "$.status" is 422 - And the response property "$.code" is "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @qod_provisioning_retrieveQoSProfiles_422.5_unnecessary_device_identifier_in_request - Scenario: Explicit device identifier provided when device is identified by the access token - Given the request body property "$.device" is set to a valid testing device - And the header "Authorization" is set to a valid access token for that same device - 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" - And the response property "$.status" is 422 - And the response property "$.code" is "UNNECESSARY_IDENTIFIER" - 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 index ea4ddb76d2..f52be14090 100644 --- a/code/Test_definitions/quality-on-demand-createSession.feature +++ b/code/Test_definitions/quality-on-demand-createSession.feature @@ -5,13 +5,13 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession # * 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. + # * 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 wip + # References to OAS spec schemas refer to schemas specified in quality-on-demand.yaml, version wip Background: Common createSession setup Given an environment at "apiRoot" @@ -19,13 +19,13 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession 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 + # Properties not explicitly overwritten 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 + Scenario: Common validations for any success 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 @@ -34,17 +34,17 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession 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 header "x-correlator" has the 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 + # 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 + # sinkCredentials not explicitly mentioned to be returned if present, as this is debatable 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" @@ -56,7 +56,7 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession 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 "$.sink" is set to a URL where 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 @@ -86,6 +86,108 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession And the response body complies with the OAS schema at "/components/schemas/SessionInfo" And the response property "$.device" does not exist + # Common error scenarios for management of input parameter device + + @quality_on_demand_createSession_C01.01_device_empty + Scenario: The device value is an empty object + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is set to: {} + When the HTTP "POST" request is sent + Then the response status code is 400 + 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_C01.02_device_identifiers_not_schema_compliant + Scenario Outline: Some device identifier value does not comply with the schema + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "" does not comply with the OAS schema at "" + When the HTTP "POST" request is sent + Then the response status code is 400 + 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/DeviceIpv4Addr | + | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | + | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | + + + # This scenario may happen e.g. with 2-legged access tokens, which do not identify a single device. + @quality_on_demand_createSession_C01.03_device_not_found + Scenario: Some identifier cannot be matched to a device + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is compliant with the schema but does not identify a valid device + When the HTTP "POST" request is sent + Then the response status code is 404 + And the response property "$.status" is 404 + And the response property "$.code" is "IDENTIFIER_NOT_FOUND" + And the response property "$.message" contains a user friendly text + + + @quality_on_demand_createSession_C02.04_unnecessary_device + Scenario: Device not to be included when it can be deduced from the access token + Given the header "Authorization" is set to a valid access token identifying a device + And the request body property "$.device" is set to a valid device + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNNECESSARY_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @quality_on_demand_createSession_C01.05_missing_device + Scenario: Device not included and cannot be deduced from the access token + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is not included + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "MISSING_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @quality_on_demand_createSession_C01.06_unsupported_device + Scenario: None of the provided device identifiers is supported by the implementation + Given that some types of device identifiers are not supported by the implementation + And the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" only includes device identifiers not supported by the implementation + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + # When the service is only offered to certain types of devices or subscriptions, e.g. IoT, B2C, etc. + @quality_on_demand_createSession_C01.07_device_not_supported + Scenario: Service not available for the device + Given that the service is not available for all devices commercialized by the operator + And a valid device, identified by the token or provided in the request body, for which the service is not applicable + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "SERVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user-friendly text + + + # Several identifiers provided but they do not identify the same device + # This scenario may happen with 2-legged access tokens, which do not identify a device + @quality_on_demand_createSession_C01.08_device_identifiers_mismatch + Scenario: Device identifiers mismatch + Given the header "Authorization" is set to a valid access token which does not identify a single device + And at 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 HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "IDENTIFIER_MISMATCH" + And the response property "$.message" contains a user friendly text + # Errors 400 @quality_on_demand_createSession_400.1_schema_not_compliant @@ -134,33 +236,11 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession 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 - # Note that device schema validation errors (if any) should be thrown even if a 3-legged access token is being used - 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 "" - And a 2-legged or 3-legged access token is being used - 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/DeviceIpv4Addr | - | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | - | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | - # 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 @@ -288,21 +368,6 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession And the response property "$.code" is "PERMISSION_DENIED" 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 "IDENTIFIER_NOT_FOUND" - And the response property "$.message" contains a user friendly text - # Errors 409 @quality_on_demand_createSession_409.1_session_conflict @@ -316,96 +381,3 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession 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 - - @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_IDENTIFIER" - 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 "IDENTIFIER_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 "SERVICE_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 "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 422 - And the response property "$.code" is "SERVICE_NOT_APPLICABLE" - And the response property "$.message" contains a user friendly text - - # Typically with a 2-legged access token - @quality_on_demand_createSession_422.5_unidentifiable_device - Scenario: Device not included and cannot be deduced from the access token - Given the header "Authorization" is set to a valid access token which does not identify a 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 "MISSING_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @quality_on_demand_createSession_422.6_device_token_mismatch - Scenario: Inconsistent access token context for the device - # To test this, a token has 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 obtained for a 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 "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @quality_on_demand_createSession_422.7_unnecessary_device_identifier_in_request - Scenario: Explicit device identifier provided when device is identified by the access token - Given the request body property "$.device" is set to a valid testing device - And the header "Authorization" is set to a valid access token for that same 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 "UNNECESSARY_IDENTIFIER" - 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 index d1e069e403..000355e12c 100644 --- a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature +++ b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature @@ -55,44 +55,113 @@ Feature: CAMARA Quality On Demand API, vwip - Operation retrieveSessionsByDevice And the response header "x-correlator" has same value as the request header "x-correlator" And the response body is [] - # Errors 400 + # Common error scenarios for management of input parameter device - @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 + @quality_on_demand_retrieveSessionsByDevice_C01.01_device_empty + Scenario: The device value is an empty object + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is set to: {} + When the HTTP "POST" request 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 + + @quality_on_demand_retrieveSessionsByDevice_C01.02_device_identifiers_not_schema_compliant + Scenario Outline: Some device identifier value does not comply with the schema + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "" does not comply with the OAS schema at "" + When the HTTP "POST" request 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/DeviceIpv4Addr | + | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | + | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | + + + # This scenario may happen e.g. with 2-legged access tokens, which do not identify a single device. + @quality_on_demand_retrieveSessionsByDevice_C01.03_device_not_found + Scenario: Some identifier cannot be matched to a device + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is compliant with the schema but does not identify a valid device + When the HTTP "POST" request is sent + Then the response status code is 404 + And the response property "$.status" is 404 + And the response property "$.code" is "IDENTIFIER_NOT_FOUND" + 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" + + @quality_on_demand_retrieveSessionsByDevice_C02.04_unnecessary_device + Scenario: Device not to be included when it can be deduced from the access token + Given the header "Authorization" is set to a valid access token identifying a device + And the request body property "$.device" is set to a valid device + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNNECESSARY_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @quality_on_demand_retrieveSessionsByDevice_C01.05_missing_device + Scenario: Device not included and cannot be deduced from the access token + Given the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" is not included + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "MISSING_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + @quality_on_demand_retrieveSessionsByDevice_C01.06_unsupported_device + Scenario: None of the provided device identifiers is supported by the implementation + Given that some types of device identifiers are not supported by the implementation + And the header "Authorization" is set to a valid access token which does not identify a single device + And the request body property "$.device" only includes device identifiers not supported by the implementation + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "UNSUPPORTED_IDENTIFIER" + And the response property "$.message" contains a user-friendly text + + + # When the service is only offered to certain types of devices or subscriptions, e.g. IoT, B2C, etc. + @quality_on_demand_retrieveSessionsByDevice_C01.07_device_not_supported + Scenario: Service not available for the device + Given that the service is not available for all devices commercialized by the operator + And a valid device, identified by the token or provided in the request body, for which the service is not applicable + When the HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "SERVICE_NOT_APPLICABLE" + And the response property "$.message" contains a user-friendly text + + + # Several identifiers provided but they do not identify the same device + # This scenario may happen with 2-legged access tokens, which do not identify a device + @quality_on_demand_retrieveSessionsByDevice_C01.08_device_identifiers_mismatch + Scenario: Device identifiers mismatch + Given the header "Authorization" is set to a valid access token which does not identify a single device + And at 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 HTTP "POST" request is sent + Then the response status code is 422 + And the response property "$.status" is 422 + And the response property "$.code" is "IDENTIFIER_MISMATCH" 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 {} + # 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" @@ -101,10 +170,9 @@ Feature: CAMARA Quality On Demand API, vwip - Operation retrieveSessionsByDevice 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 "" + @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" @@ -113,24 +181,15 @@ Feature: CAMARA Quality On Demand API, vwip - Operation retrieveSessionsByDevice 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/DeviceIpv4Addr | - | $.device.ipv6Address | /components/schemas/DeviceIpv6Address | - | $.device.networkIdentifier | /components/schemas/NetworkAccessIdentifier | - - # 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 + @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 "OUT_OF_RANGE" or "INVALID_ARGUMENT" + And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text # Generic 401 errors @@ -185,96 +244,3 @@ Feature: CAMARA Quality On Demand API, vwip - Operation retrieveSessionsByDevice And the response property "$.code" is "PERMISSION_DENIED" 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 "IDENTIFIER_NOT_FOUND" - And the response property "$.message" contains a user friendly text - - # Errors 422 - - @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 "UNSUPPORTED_IDENTIFIER" - 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 "IDENTIFIER_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 "SERVICE_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 deduced from the access token - Given the header "Authorization" is set to a valid access token which does not identify a 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 "MISSING_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @quality_on_demand_retrieveSessionsByDevice_422.5_device_token_mismatch - Scenario: Inconsistent access token context for the device - # To test this, a token has 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 obtained for a 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 "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text - - # Typically with a 3-legged access token - @quality_on_demand_retrieveSessionsByDevice_422.6_unnecessary_device_identifier_in_request - Scenario: Explicit device identifier provided when device is identified by the access token - Given the request body property "$.device" is set to a valid testing device - And the header "Authorization" is set to a valid access token for that same 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 "UNNECESSARY_IDENTIFIER" - And the response property "$.message" contains a user friendly text From a76f67c024fc600ee037b39efea5903be66abd6d Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Mon, 27 Jan 2025 17:43:51 +0000 Subject: [PATCH 2/8] Update code/Test_definitions/README.md --- code/Test_definitions/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/Test_definitions/README.md b/code/Test_definitions/README.md index d7776ccf7b..7d4818940c 100644 --- a/code/Test_definitions/README.md +++ b/code/Test_definitions/README.md @@ -8,7 +8,7 @@ The test plan has to be enhanced and some scenarios still contains comments and * 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 -* 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 +* 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 SERVICE_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 * For QoS Profile response validations, it is pending to check additional constraints, such as minDuration being less or equal than maxDuration, etc From 63133b355b40237f6bb3a99274fb8e90badd2f7f Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Mon, 27 Jan 2025 20:48:23 +0000 Subject: [PATCH 3/8] Update code/Test_definitions/qod-provisioning-createProvisioning.feature --- .../qod-provisioning-createProvisioning.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/Test_definitions/qod-provisioning-createProvisioning.feature b/code/Test_definitions/qod-provisioning-createProvisioning.feature index b53a940942..2bf27d17a8 100644 --- a/code/Test_definitions/qod-provisioning-createProvisioning.feature +++ b/code/Test_definitions/qod-provisioning-createProvisioning.feature @@ -120,7 +120,7 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation createProvisioning And the response property "$.message" contains a user friendly text - @qod_provisioning_createProvisioning_C02.04_unnecessary_device + @qod_provisioning_createProvisioning_C01.04_unnecessary_device Scenario: Device not to be included when it can be deduced from the access token Given the header "Authorization" is set to a valid access token identifying a device And the request body property "$.device" is set to a valid device From 6eea16cd4b6d21481de84e4abdba5bd09445b9cc Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Mon, 27 Jan 2025 21:00:59 +0000 Subject: [PATCH 4/8] Update code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature --- .../qod-provisioning-retrieveProvisioningByDevice.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature index a4b2d69e44..1d7b194b85 100644 --- a/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature +++ b/code/Test_definitions/qod-provisioning-retrieveProvisioningByDevice.feature @@ -84,7 +84,7 @@ Feature: CAMARA QoD Provisioning API, vwip - Operation retrieveProvisioningByDev And the response property "$.message" contains a user friendly text - @qod_provisioning_retrieveProvisioningByDevice_C02.04_unnecessary_device +@qod_provisioning_retrieveProvisioningByDevice_C01.04_unnecessary_device Scenario: Device not to be included when it can be deduced from the access token Given the header "Authorization" is set to a valid access token identifying a device And the request body property "$.device" is set to a valid device From 6e05d71bd8b999ee35dad062ee719bdae50f9481 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Mon, 27 Jan 2025 21:03:22 +0000 Subject: [PATCH 5/8] Update code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature --- code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature index 79c4680467..a9717b455f 100644 --- a/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature +++ b/code/Test_definitions/qos-profiles-retrieveQoSProfiles.feature @@ -139,7 +139,7 @@ Feature: CAMARA QoS Profiles API, vwip - Operation retrieveQoSProfiles And the response property "$.message" contains a user friendly text - @qos_profiles_retrieveQoSProfiles_C02.04_unnecessary_device + @qos_profiles_retrieveQoSProfiles_C01.04_unnecessary_device Scenario: Device not to be included when it can be deduced from the access token Given the header "Authorization" is set to a valid access token identifying a device And the request body property "$.device" is set to a valid device From a7757836875ae336272818f7bc18dd6308e8f723 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Mon, 27 Jan 2025 21:10:07 +0000 Subject: [PATCH 6/8] Update code/Test_definitions/quality-on-demand-createSession.feature --- code/Test_definitions/quality-on-demand-createSession.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/Test_definitions/quality-on-demand-createSession.feature b/code/Test_definitions/quality-on-demand-createSession.feature index f52be14090..d8ce29fa25 100644 --- a/code/Test_definitions/quality-on-demand-createSession.feature +++ b/code/Test_definitions/quality-on-demand-createSession.feature @@ -129,7 +129,7 @@ Feature: CAMARA Quality On Demand API, vwip - Operation createSession And the response property "$.message" contains a user friendly text - @quality_on_demand_createSession_C02.04_unnecessary_device + @quality_on_demand_createSession_C01.04_unnecessary_device Scenario: Device not to be included when it can be deduced from the access token Given the header "Authorization" is set to a valid access token identifying a device And the request body property "$.device" is set to a valid device From a0b7f8db9cd34e0fa72723be2dacc58eaa0cd8a8 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Mon, 27 Jan 2025 21:17:21 +0000 Subject: [PATCH 7/8] Update code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature --- .../quality-on-demand-retrieveSessionsByDevice.feature | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature index 000355e12c..046e8c41e5 100644 --- a/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature +++ b/code/Test_definitions/quality-on-demand-retrieveSessionsByDevice.feature @@ -98,7 +98,7 @@ Feature: CAMARA Quality On Demand API, vwip - Operation retrieveSessionsByDevice And the response property "$.message" contains a user friendly text - @quality_on_demand_retrieveSessionsByDevice_C02.04_unnecessary_device + @quality_on_demand_retrieveSessionsByDevice_C01.04_unnecessary_device Scenario: Device not to be included when it can be deduced from the access token Given the header "Authorization" is set to a valid access token identifying a device And the request body property "$.device" is set to a valid device From 5677542a5fe375d9691d0949290c7a2e4098ee85 Mon Sep 17 00:00:00 2001 From: Eric Murray Date: Mon, 27 Jan 2025 21:28:11 +0000 Subject: [PATCH 8/8] Update README.md --- code/Test_definitions/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/code/Test_definitions/README.md b/code/Test_definitions/README.md index 7d4818940c..ef1f784a99 100644 --- a/code/Test_definitions/README.md +++ b/code/Test_definitions/README.md @@ -3,7 +3,6 @@ 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