From 131b2b4e7384255df5d4782e62e3b01aaac5679a Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 20:46:29 +0100 Subject: [PATCH 01/11] Enable Gherkin Linting --- .../carrier-billing-cancelPayment.feature | 19 +------- .../carrier-billing-confirmPayment.feature | 20 +------- .../carrier-billing-createPayment.feature | 34 +------------- .../carrier-billing-preparePayment.feature | 47 +++---------------- ...arrier-billing-refund-createRefund.feature | 47 +++---------------- ...und-retrievePaymentRemainingAmount.feature | 31 ++++-------- ...rier-billing-refund-retrieveRefund.feature | 16 ++----- ...ier-billing-refund-retrieveRefunds.feature | 32 +++---------- .../carrier-billing-retrievePayment.feature | 13 +---- .../carrier-billing-retrievePayments.feature | 25 +--------- .../carrier-billing-validatePayment.feature | 20 ++------ 11 files changed, 42 insertions(+), 262 deletions(-) diff --git a/code/Test_definitions/carrier-billing-cancelPayment.feature b/code/Test_definitions/carrier-billing-cancelPayment.feature index adb0b8d..fdce2cc 100644 --- a/code/Test_definitions/carrier-billing-cancelPayment.feature +++ b/code/Test_definitions/carrier-billing-cancelPayment.feature @@ -21,7 +21,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment # Happy path scenarios ############################## - @cancel_payment_01_generic_success_scenario Scenario: Common validations for any success scenario # Valid default request body compliant with the schema @@ -31,27 +30,24 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response header "Content-Type" is "application/json" And the response header "x-correlator" has same value as the request header "x-correlator" - @cancel_payment_02_phoneNumber_three_legged # Case using a 3-legged Access Token - Scenario: Request cancel payment indicating phoneNumber + Scenario: Request cancel payment indicating phoneNumber in 3-legged access mode Given the request body property "$.phonenumber" is set to a valid value which is the same as associated to access token When the HTTP "POST" request is sent Then the response status code is 202 And the response header "Content-Type" is "application/json" And the response header "x-correlator" has same value as the request header "x-correlator" - @cancel_payment_03_phoneNumber_two_legged # Case using a 2-legged Access Token. Only applicable for Countries and Telco Operators whose regulation allows for it - Scenario: Request cancel payment indicating phoneNumber + Scenario: Request cancel payment indicating phoneNumber in 2-legged access mode Given the request body property "$.phonenumber" is set to a valid value which is the same as associated to access token When the HTTP "POST" request is sent Then the response status code is 202 And the response header "Content-Type" is "application/json" And the response header "x-correlator" has same value as the request header "x-correlator" - ############################## # Error scenarios ############################## @@ -67,7 +63,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @cancel_payment_400.02_empty_request_body Scenario: Empty object as request body Given the request body is set to "{}" @@ -77,7 +72,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - # Error 401 scenarios @cancel_payment_401.01_no_authorization_header @@ -90,7 +84,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @cancel_payment_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -101,7 +94,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @cancel_payment_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -113,7 +105,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @cancel_payment_403.01_invalid_token_permissions @@ -127,7 +118,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @cancel_payment_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -139,7 +129,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - # Error 409 scenarios @cancel_payment_409.01_payment_confirmed @@ -153,7 +142,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "CARRIER_BILLING.PAYMENT_CONFIRMED" And the response property "$.message" contains a user friendly text - @cancel_payment_409.02_payment_cancelled Scenario: Payment already cancelled Given the request body is set to a valid request body @@ -165,7 +153,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "CARRIER_BILLING.PAYMENT_CANCELLED" And the response property "$.message" contains a user friendly text - # Error 422 scenarios @cancel_payment_422.01_phoneNumber_required @@ -179,8 +166,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment And the response property "$.code" is "CARRIER_BILLING.PHONE_NUMBER_REQUIRED" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-confirmPayment.feature b/code/Test_definitions/carrier-billing-confirmPayment.feature index c6e8f17..fd4f7b3 100644 --- a/code/Test_definitions/carrier-billing-confirmPayment.feature +++ b/code/Test_definitions/carrier-billing-confirmPayment.feature @@ -22,7 +22,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment # Happy path scenarios ############################## - @confirm_payment_01_generic_success_scenario Scenario: Common validations for any success scenario # Valid default request body compliant with the schema @@ -32,27 +31,24 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response header "Content-Type" is "application/json" And the response header "x-correlator" has same value as the request header "x-correlator" - @confirm_payment_02_phoneNumber_three_legged # Case using a 3-legged Access Token - Scenario: Request confirm payment indicating phoneNumber + Scenario: Request confirm payment indicating phoneNumber in 3-legged access mode Given the request body property "$.phonenumber" is set to a valid value which is the same as associated to access token When the HTTP "POST" request is sent Then the response status code is 202 And the response header "Content-Type" is "application/json" And the response header "x-correlator" has same value as the request header "x-correlator" - @confirm_payment_03_phoneNumber_two_legged # Case using a 2-legged Access Token. Only applicable for Countries and Telco Operators whose regulation allows for it - Scenario: Request confirm payment indicating phoneNumber + Scenario: Request confirm payment indicating phoneNumber in 2-legged access mode Given the request body property "$.phonenumber" is set to a valid value which is the same as associated to access token When the HTTP "POST" request is sent Then the response status code is 202 And the response header "Content-Type" is "application/json" And the response header "x-correlator" has same value as the request header "x-correlator" - ############################## # Error scenarios ############################## @@ -68,7 +64,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @confirm_payment_400.02_empty_request_body Scenario: Empty object as request body Given the request body is set to "{}" @@ -78,7 +73,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - # Error 401 scenarios @confirm_payment_401.01_no_authorization_header @@ -91,7 +85,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @confirm_payment_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -102,7 +95,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @confirm_payment_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -114,7 +106,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @confirm_payment_403.01_invalid_token_permissions @@ -128,7 +119,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @confirm_payment_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -140,7 +130,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - @confirm_payment_403.02_payment_denied Scenario: Payment denied by business # To test this, a business context exists in the Telco Operator to deny the payment @@ -152,7 +141,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "CARRIER_BILLING.PAYMENT_DENIED" And the response property "$.message" contains a user friendly text - # Error 409 scenarios @confirm_payment_409.01_payment_confirmed @@ -166,7 +154,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "CARRIER_BILLING.PAYMENT_CONFIRMED" And the response property "$.message" contains a user friendly text - @confirm_payment_409.02_payment_cancelled Scenario: Payment already cancelled Given the request body is set to a valid request body @@ -178,7 +165,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "CARRIER_BILLING.PAYMENT_CANCELLED" And the response property "$.message" contains a user friendly text - # Error 422 scenarios @confirm_payment_422.01_phoneNumber_required @@ -192,8 +178,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment And the response property "$.code" is "CARRIER_BILLING.PHONE_NUMBER_REQUIRED" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-createPayment.feature b/code/Test_definitions/carrier-billing-createPayment.feature index d547515..19e00c8 100644 --- a/code/Test_definitions/carrier-billing-createPayment.feature +++ b/code/Test_definitions/carrier-billing-createPayment.feature @@ -21,7 +21,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment # Happy path scenarios ############################## - @create_payment_01_generic_success_scenario Scenario: Common validations for any success scenario # Valid default request body compliant with the schema @@ -35,7 +34,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment # 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/PaymentCreated" - @create_payment_02_generic_success_scenario_with_sink_information Scenario: Common validations for any success scenario with sink information provided # Property "$.amountTransaction" is set with required information only @@ -50,7 +48,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment # 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/PaymentCreated" - @create_payment_03_generic_success_scenario_with_sink_and_sinkCredential_information Scenario: Common validations for any success scenario sink and sinkCredential information provided # Property "$.amountTransaction" is set with required information only @@ -67,7 +64,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment # 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/PaymentCreated" - # Scenarios testing specific situations for amountTransaction @create_payment_04_amountTransaction_gross_amount @@ -81,7 +77,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.amountTransaction.paymentAmount.chargingInformation.isTaxIncluded" is true - @create_payment_05_amountTransaction_net_amount Scenario: Request 1-step payment with net amount Given the request body property "$.amountTransaction" is set with valid required information @@ -93,7 +88,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.amountTransaction.paymentAmount.chargingInformation.isTaxIncluded" is false OR not returned - @create_payment_06_amountTransaction_taxAmount Scenario: Request 1-step payment indicating taxAmount Given the request body property "$.amountTransaction" is set with valid required information @@ -105,7 +99,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.amountTransaction.paymentAmount.chargingInformation.taxAmount" has the same value as provided in the request body - @create_payment_07_amountTransaction_merchantIdentifier # May be relevant scenario for Payment Aggregator Case Scenario: Request 1-step payment indicating merchantIdentifier @@ -118,7 +111,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.amountTransaction.paymentAmount.chargingMetaData.merchantIdentifier" has the same value as provided in the request body - @create_payment_08_amountTransaction_paymentDetails Scenario: Request 1-step payment indicating merchantIdentifier Given the request body property "$.amountTransaction" is set with valid required information @@ -130,7 +122,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body array property "$.amountTransaction.paymentAmount.paymentDetails" has the same information as provided in the request body - @create_payment_09_amountTransaction_clientCorrelator # Recommended scenario to manage request idempotency Scenario: Request 1-step payment indicating clientCorrelator @@ -143,7 +134,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.amountTransaction.clientCorrelator" has the same value as provided in the request body - @create_payment_10_amountTransaction_phoneNumber_three_legged # Case using a 3-legged Access Token emitted for a specific phone number Scenario: Request 1-step payment indicating phoneNumber @@ -156,7 +146,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.amountTransaction.phoneNumber" has the same value as provided in the request body - @create_payment_11_amountTransaction_phoneNumber_two_legged # Case using a 2-legged Access Token. Only applicable for Countries and Telco Operators whose regulation allows for it Scenario: Request 1-step payment indicating phoneNumber @@ -169,7 +158,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.amountTransaction.phoneNumber" has the same value as provided in the request body - @create_payment_12_sync_behaviour # Scenario for a Telco Operator that behaves synchronously Scenario: Request 1-step payment with sync behaviour @@ -181,7 +169,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.paymentStatus" is "succeeded" - @create_payment_13_async_behaviour # Scenario for a Telco Operator that behaves asynchronously Scenario: Request 1-step payment with async behaviour @@ -193,7 +180,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body complies with the OAS schema at "/components/schemas/PaymentCreated" And the response body property "$.paymentStatus" is "processing" - ############################## # Error scenarios ############################## @@ -209,7 +195,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_payment_400.02_empty_request_body Scenario: Empty object as request body Given the request body is set to "{}" @@ -219,7 +204,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_payment_400.03_other_input_properties_schema_not_compliant # Test other input properties in addition to amountTransaction Scenario Outline: Input property values does not comply with the schema @@ -233,8 +217,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment Examples: | input_property | oas_spec_schema | | $.sink | /components/schemas/CreatePayment | - | $.sinkCredential | /components/schemas/SinkCredential | | - + | $.sinkCredential | /components/schemas/SinkCredential | @create_payment_400.04_required_input_properties_missing Scenario Outline: Required input properties are missing @@ -255,7 +238,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment | $.amountTransaction.paymentAmount.chargingInformation.currency | | $.amountTransaction.paymentAmount.chargingInformation.description | - @create_payment_400.05_clientCorrelator_in_use Scenario: Using the same client correlator for two different payment requests Given the request body property includes property "$.clientCorrelator" with a value already use in a non-completed payment @@ -265,7 +247,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_payment_400.06_invalid_sink Scenario: Using a invalid sink value Given the request body property includes property "$.sink" which is not set to an url @@ -275,7 +256,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_payment_400.07_invalid_sinkCredential Scenario: Using a invalid sinkCredential type value Given the request body property includes property "$.sinkCredential.credentialType" whose value is not "ACCESSTOKEN" @@ -285,7 +265,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "INVALID_CREDENTIAL" And the response property "$.message" contains a user friendly text - @create_payment_400.08_invalid_sinkCredential_Acccestoken Scenario: Using a invalid sinkCredential accesstoken type value Given the request body property includes property "$.sinkCredential.accessTokenType" whose value is not "bearer" @@ -307,7 +286,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @create_payment_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -318,7 +296,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @create_payment_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -330,7 +307,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @create_payment_403.01_invalid_token_permissions @@ -344,7 +320,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @create_payment_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -356,7 +331,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - @create_payment_403.03_payment_denied Scenario: Payment denied by business # To test this, a business context exists in the Telco Operator to deny the payment @@ -368,7 +342,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "CARRIER_BILLING.PAYMENT_DENIED" And the response property "$.message" contains a user friendly text - # Error 409 scenarios @create_payment_409.01_payment_duplicated @@ -383,7 +356,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "ALREADY_EXISTS" And the response property "$.message" contains a user friendly text - # Error 422 scenarios @create_payment_422.01_phoneNumber_required @@ -397,7 +369,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "CARRIER_BILLING.PHONE_NUMBER_REQUIRED" And the response property "$.message" contains a user friendly text - @create_payment_422.02_unauthorized_amount Scenario: Payment amount exceeds the value allowed by the regulation # This test applies/depends on the regulation applicable for a given Country @@ -410,7 +381,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "CARRIER_BILLING.UNAUTHORIZED_AMOUNT" And the response property "$.message" contains a user friendly text - @create_payment_422.02_accumulated_threshold_amount_overpassed Scenario: Payment amount exceeds the accumulated threshold amount value allowed by the regulation # This test applies/depends on the regulation applicable for a given Country @@ -423,8 +393,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response property "$.code" is "CARRIER_BILLING.AMOUNT_THRESHOLD_OVERPASSED" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-preparePayment.feature b/code/Test_definitions/carrier-billing-preparePayment.feature index e24b679..f990362 100644 --- a/code/Test_definitions/carrier-billing-preparePayment.feature +++ b/code/Test_definitions/carrier-billing-preparePayment.feature @@ -3,7 +3,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment # # Implementation indications: # * Telco Operator carrier billing behaviour mode: sync or async - # + # # Testing assets: # * A phone number eligible for payment (no restrictions for it to be used to perform a payment) # * A phone number not-eligible for payment (payment is denied for it due to business conditions) @@ -21,7 +21,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment # Happy path scenarios ############################## - @prepare_payment_01_generic_success_scenario Scenario: Common validations for any success scenario # Valid default request body compliant with the schema @@ -35,7 +34,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment # 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/BodyAmountReservationTransactionForReserve" - @prepare_payment_02_generic_success_scenario_with_sink_information Scenario: Common validations for any success scenario with sink information provided # Property "$.amountTransaction" is set with required information only @@ -50,7 +48,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment # 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/BodyAmountReservationTransactionForReserve" - @prepare_payment_03_generic_success_scenario_with_sink_and_sinkCredential_information Scenario: Common validations for any success scenario sink and sinkCredential information provided # Property "$.amountTransaction" is set with required information only @@ -67,7 +64,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment # 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/BodyAmountReservationTransactionForReserve" - # Scenarios testing specific situations for amountTransaction @prepare_payment_04_amountTransaction_gross_amount @@ -81,7 +77,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.amountTransaction.paymentAmount.chargingInformation.isTaxIncluded" is true - @prepare_payment_05_amountTransaction_net_amount Scenario: Request 2-step payment with net amount Given the request body property "$.amountTransaction" is set with valid required information @@ -93,7 +88,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.amountTransaction.paymentAmount.chargingInformation.isTaxIncluded" is false OR not returned - @prepare_payment_06_amountTransaction_taxAmount Scenario: Request 2-step payment indicating taxAmount Given the request body property "$.amountTransaction" is set with valid required information @@ -105,7 +99,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.amountTransaction.paymentAmount.chargingInformation.taxAmount" has the same value as provided in the request body - @prepare_payment_07_amountTransaction_merchantIdentifier # May be relevant scenario for Payment Aggregator Case Scenario: Request 2-step payment indicating merchantIdentifier @@ -118,9 +111,8 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.amountTransaction.paymentAmount.chargingMetaData.merchantIdentifier" has the same value as provided in the request body - @prepare_payment_08_amountTransaction_paymentDetails - Scenario: Request 2-step payment indicating merchantIdentifier + Scenario: Request 2-step payment indicating paymentDetails Given the request body property "$.amountTransaction" is set with valid required information And the request body array property "$.amountTransaction.paymentAmount.paymentDetails" is set with valid information When the HTTP "POST" request is sent @@ -130,7 +122,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body array property "$.amountTransaction.paymentAmount.paymentDetails" has the same information as provided in the request body - @prepare_payment_09_amountTransaction_clientCorrelator # Recommended scenario to manage request idempotency Scenario: Request 2-step payment indicating clientCorrelator @@ -143,10 +134,9 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.amountTransaction.clientCorrelator" has the same value as provided in the request body - @prepare_payment_10_amountTransaction_phoneNumber_three_legged # Case using a 3-legged Access Token identifying a specific phone number - Scenario: Request 2-step payment indicating phoneNumber + Scenario: Request 2-step payment indicating phoneNumber in 3-legged access mode Given the request body property "$.amountTransaction" is set with valid required information And the request body property "$.amountTransaction.phoneNumber" is set to a valid value which is the same as associated to access token When the HTTP "POST" request is sent @@ -156,10 +146,9 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.amountTransaction.phoneNumber" has the same value as provided in the request body - @prepare_payment_11_amountTransaction_phoneNumber_two_legged # Case using a 2-legged Access Token. Only applicable for Countries and Operators whose regulation allows for it - Scenario: Request 2-step payment indicating phoneNumber + Scenario: Request 2-step payment indicating phoneNumber in 2-legged access mode Given the request body property "$.amountTransaction" is set with valid required information And the request body property "$.amountTransaction.phoneNumber" is set to a valid value When the HTTP "POST" request is sent @@ -169,10 +158,9 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.amountTransaction.phoneNumber" has the same value as provided in the request body - @prepare_payment_12_sync_behaviour_without_validation_info # Scenario for a Telco Operator that behaves synchronously - Scenario: Request 2-step payment with sync behaviour + Scenario: Request 2-step payment with sync behaviour without validation info in response Given the request body property "$.amountTransaction" is set with valid required information When the HTTP "POST" request is sent Then the response status code is 201 @@ -182,10 +170,9 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.validatioInfo" is not returned And the response body property "$.paymentStatus" is "reserved" - @prepare_payment_13_sync_behaviour_with_validation_info # Scenario for a Telco Operator that behaves synchronously - Scenario: Request 2-step payment with sync behaviour + Scenario: Request 2-step payment with sync behaviour with validation info in response Given the request body property "$.amountTransaction" is set with valid required information When the HTTP "POST" request is sent Then the response status code is 201 @@ -195,7 +182,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.validatioInfo" is returned And the response body property "$.paymentStatus" is "pending_validation" - @prepare_payment_14_async_behaviour # Scenario for a Telco Operator that behaves asynchronously Scenario: Request 2-step payment with async behaviour @@ -207,7 +193,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response body complies with the OAS schema at "/components/schemas/BodyAmountReservationTransactionForReserve" And the response body property "$.paymentStatus" is "processing" - ############################## # Error scenarios ############################## @@ -223,7 +208,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @prepare_payment_400.02_empty_request_body Scenario: Empty object as request body Given the request body is set to "{}" @@ -233,7 +217,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @prepare_payment_400.03_other_input_properties_schema_not_compliant # Test other input properties in addition to amountTransaction Scenario Outline: Input property values does not comply with the schema @@ -247,8 +230,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment Examples: | input_property | oas_spec_schema | | $.sink | /components/schemas/CreatePayment | - | $.sinkCredential | /components/schemas/SinkCredential | | - + | $.sinkCredential | /components/schemas/SinkCredential | @prepare_payment_400.04_required_input_properties_missing Scenario Outline: Required input properties are missing @@ -269,7 +251,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment | $.amountTransaction.paymentAmount.chargingInformation.currency | | $.amountTransaction.paymentAmount.chargingInformation.description | - @prepare_payment_400.05_clientCorrelator_in_use Scenario: Using the same client correlator for two different payment requests Given the request body property includes property "$.clientCorrelator" with a value already use in a non-completed payment @@ -279,7 +260,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @prepare_payment_400.06_invalid_sink Scenario: Using a invalid sink value Given the request body property includes property "$.sink" which is not set to an url @@ -289,7 +269,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @prepare_payment_400.07_invalid_sinkCredential Scenario: Using a invalid sinkCredential type value Given the request body property includes property "$.sinkCredential.credentialType" whose value is not "ACCESSTOKEN" @@ -299,7 +278,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "INVALID_CREDENTIAL" And the response property "$.message" contains a user friendly text - @prepare_payment_400.08_invalid_sinkCredential_Acccestoken Scenario: Using a invalid sinkCredential accesstoken type value Given the request body property includes property "$.sinkCredential.accessTokenType" whose value is not "bearer" @@ -321,7 +299,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @prepare_payment_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -332,7 +309,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @prepare_payment_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -344,7 +320,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @prepare_payment_403.01_invalid_token_permissions @@ -358,7 +333,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @prepare_payment_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -370,7 +344,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - @prepare_payment_403.03_payment_denied Scenario: Payment denied by business # To test this, a business context exists in the Telco Operator to deny the payment @@ -382,7 +355,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "CARRIER_BILLING.PAYMENT_DENIED" And the response property "$.message" contains a user friendly text - # Error 409 scenarios @prepare_payment_409.01_payment_duplicated @@ -397,7 +369,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "ALREADY_EXISTS" And the response property "$.message" contains a user friendly text - # Error 422 scenarios @prepare_payment_422.01_phoneNumber_required @@ -411,7 +382,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "CARRIER_BILLING.PHONE_NUMBER_REQUIRED" And the response property "$.message" contains a user friendly text - @prepare_payment_422.02_unauthorized_amount Scenario: Payment amount exceeds the value allowed by the regulation # This test applies/depends on the regulation applicable for a given Country @@ -424,7 +394,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "CARRIER_BILLING.UNAUTHORIZED_AMOUNT" And the response property "$.message" contains a user friendly text - @prepare_payment_422.02_accumulated_threshold_amount_overpassed Scenario: Payment amount exceeds the accumulated threshold amount value allowed by the regulation # This test applies/depends on the regulation applicable for a given Country @@ -437,8 +406,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment And the response property "$.code" is "CARRIER_BILLING.AMOUNT_THRESHOLD_OVERPASSED" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-refund-createRefund.feature b/code/Test_definitions/carrier-billing-refund-createRefund.feature index 4e21e1e..e951cf2 100644 --- a/code/Test_definitions/carrier-billing-refund-createRefund.feature +++ b/code/Test_definitions/carrier-billing-refund-createRefund.feature @@ -3,7 +3,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund # # Implementation indications: # * Telco Operator carrier billing refund behaviour mode: sync or async - # + # # Testing assets: # * A phone number eligible for payment & refund (no restrictions for it to be used to perform a payment or refund) # * A phone number not-eligible for refund (refund is denied for it due to business conditions) @@ -22,7 +22,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund # Happy path scenarios ############################## - @create_refunds_01_generic_success_scenario Scenario: Common validations for any success scenario # Valid default request body compliant with the schema @@ -38,7 +37,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund # 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/Refund" - @create_refunds_02_generic_success_scenario_with_sink_information Scenario: Common validations for any success scenario with sink information provided # Property "$.amountTransaction" is set with required information only @@ -55,7 +53,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund # 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/Refund" - @create_refunds_03_generic_success_scenario_with_sink_and_sinkCredential_information Scenario: Common validations for any success scenario sink and sinkCredential information provided # Property "$.amountTransaction" is set with required information only @@ -74,7 +71,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund # 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/Refund" - # Scenarios testing specific situations for amountTransaction @create_refunds_04_total_refund @@ -89,10 +85,9 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body property "$.type" is set "total" And the response body property "$.amountTransaction.refundAmount" is "{}" - @create_refunds_04_partial_refund_amountTransaction_gross_amount Scenario: Request partial refund with gross amount - Given the request body property "$.type" is set to "partial" + Given the request body property "$.type" is set to "partial" And the request body property "$.amountTransaction" is set with valid required information for this refund type And the request body property "$.amountTransaction.refundAmount.chargingInformation.isTaxIncluded" is set to true When the HTTP "POST" request is sent @@ -102,7 +97,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.amountTransaction.refundAmount.chargingInformation.isTaxIncluded" is true - @create_refunds_05_partial_refund_amountTransaction_net_amount Scenario: Request partial refund with net amount Given the request body property "$.type" is set to "partial" @@ -115,10 +109,9 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.amountTransaction.refundAmount.chargingInformation.isTaxIncluded" is false OR not returned - @create_refunds_06_partial_refund_amountTransaction_taxAmount Scenario: Request partial refund indicating taxAmount - Given the request body property "$.type" is set to "partial" + Given the request body property "$.type" is set to "partial" And the request body property "$.amountTransaction" is set with valid required information for this refund type And the request body property "$.amountTransaction.refundAmount.chargingInformation.taxAmount" is set to a valid value When the HTTP "POST" request is sent @@ -128,7 +121,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.amountTransaction.refundAmount.chargingInformation.taxAmount" has the same value as provided in the request body - @create_refunds_07_amountTransaction_merchantIdentifier # May be relevant scenario for Payment Aggregator Case Scenario: Request refund indicating merchantIdentifier @@ -142,10 +134,9 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.amountTransaction.refundAmount.chargingMetaData.merchantIdentifier" has the same value as provided in the request body - @create_refunds_08_partial_refund_amountTransaction_refundDetails Scenario: Request partial refund indicating indicating refundDetails - Given the request body property "$.type" is set to "partial" + Given the request body property "$.type" is set to "partial" And the request body property "$.amountTransaction" is set with valid required information for this refund type And the request body array property "$.amountTransaction.refundAmount.refundDetails" is set with valid information When the HTTP "POST" request is sent @@ -155,7 +146,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body array property "$.amountTransaction.refundAmount.refundDetails" has the same information as provided in the request body - @create_refunds_09_amountTransaction_clientCorrelator # Recommended scenario to manage request idempotency Scenario: Request refund indicating clientCorrelator @@ -169,7 +159,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.amountTransaction.clientCorrelator" has the same value as provided in the request body - @create_refunds_10_reason Scenario: Request refund indicating reason Given the request body property "$.amountTransaction" is set with valid required information @@ -182,7 +171,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.reason" has the same value as provided in the request body - @create_refunds_11_sync_behaviour # Scenario for a Telco Operator that behaves synchronously Scenario: Request refund with sync behaviour @@ -195,7 +183,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.refundStatus" is "succeeded" - @create_refunds_12_async_behaviour # Scenario for a Telco Operator that behaves asynchronously Scenario: Request refund with async behaviour @@ -208,7 +195,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response body complies with the OAS schema at "/components/schemas/Refund" And the response body property "$.refundStatus" is "processing" - ############################## # Error scenarios ############################## @@ -224,7 +210,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_refunds_400.02_empty_request_body Scenario: Empty object as request body Given the request body is set to "{}" @@ -234,7 +219,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_refunds_400.03_other_input_properties_schema_not_compliant # Test other input properties in addition to amountTransaction Scenario Outline: Input property values does not comply with the schema @@ -250,7 +234,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund | $.sink | /components/schemas/CreateRefund | | $.sinkCredential | /components/schemas/SinkCredential | | - @create_refunds_400.04_required_input_properties_missing Scenario Outline: Required input properties are missing Given the request body property "" is not included @@ -267,7 +250,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund | $.amountTransaction.refundAmount | | $.amountTransaction.referenceCode | - @create_refunds_400.05_clientCorrelator_in_use Scenario: Using the same client correlator for two different refund requests Given the request body property includes property "$.amountTransaction.clientCorrelator" with a value already use in a non-completed refund @@ -277,7 +259,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_refunds_400.06_invalid_sink Scenario: Using a invalid sink value Given the request body property includes property "$.sink" with an HTTP endpoint @@ -287,7 +268,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @create_refunds_400.07_invalid_sinkCredential Scenario: Using a invalid sinkCredential type value Given the request body property includes property "$.sinkCredential.credentialType" whose value is not "ACCESSTOKEN" @@ -297,7 +277,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "INVALID_CREDENTIAL" And the response property "$.message" contains a user friendly text - @create_refunds_400.08_invalid_sinkCredential_Acccestoken Scenario: Using a invalid sinkCredential accesstoken type value Given the request body property includes property "$.sinkCredential.accessTokenType" whose value is not "bearer" @@ -307,7 +286,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "INVALID_TOKEN" And the response property "$.message" contains a user friendly text - # Error 401 scenarios @create_refunds_401.01_no_authorization_header @@ -341,7 +319,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @create_refunds_403.01_invalid_token_permissions @@ -355,7 +332,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @create_refunds_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -367,7 +343,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - @create_refunds_403.03_refund_denied Scenario: Refund denied by business # To test this, a business context exists in the Telco Operator to deny the refund @@ -379,7 +354,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "CARRIER_BILLING_REFUND.REFUND_DENIED" And the response property "$.message" contains a user friendly text - @create_refunds_403.03_payment_not_eligible_for_refund Scenario: Payment not eligible for refund # To test this, a business context exists in the Telco Operator to not consider the payment eligible for the refund @@ -391,7 +365,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "CARRIER_BILLING_REFUND.PAYMENT_NOT_ELIGIBLE_FOR_REFUND" And the response property "$.message" contains a user friendly text - # Error 404 scenarios @create_refunds_404.01_payment_not_found @@ -405,11 +378,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "NOT_FOUND" And the response property "$.message" contains a user friendly text - # Error 409 scenarios @create_refunds_409.01_refund_duplicated - Scenario: Payment duplicated + Scenario: Refund duplicated Given the request body is set to a valid request body And the request body property "$.amountTransaction.referenceCode" is set to a value already use in another refund request And the request body property "$.amountTransaction.clientCorrelator" is missing @@ -420,7 +392,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "ALREADY_EXISTS" And the response property "$.message" contains a user friendly text - # Error 422 scenarios @create_refunds_422.01_unauthorized_amount @@ -436,7 +407,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "CARRIER_BILLING_REFUND.UNAUTHORIZED_AMOUNT" And the response property "$.message" contains a user friendly text - @create_refunds_422.02_accumulated_threshold_amount_overpassed Scenario: Refund amount exceeds the accumulated threshold amount value allowed by the regulation # This test applies/depends on the regulation applicable for a given Country @@ -450,9 +420,8 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "CARRIER_BILLING_REFUND.AMOUNT_THRESHOLD_OVERPASSED" And the response property "$.message" contains a user friendly text - @create_refunds_422.03_payment_invalid_status - Scenario: Payment duplicated + Scenario: Refund for a Payment in an invalid status Given the request body is set to a valid request body And the path parameter "paymentId" is set to a valid value of a payment whose "paymentStatus" != "succeeded" And the header "Authorization" is set to a valid access token @@ -462,7 +431,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "CARRIER_BILLING_REFUND.INVALID_PAYMENT_STATUS" And the response property "$.message" contains a user friendly text - @create_refunds_422.04_inconsistent_tax_management Scenario: Request refund with inconsistent "isTaxIncluded" Given the request body is set to a valid request body @@ -475,7 +443,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "CARRIER_BILLING_REFUND.TAXES_MANAGEMENT_MISMATCH" And the response property "$.message" contains a user friendly text - @create_refunds_422.05_inconsistent_refund_details Scenario: Request refund with inconsistent "refundDetails" Given the request body is set to a valid request body @@ -488,8 +455,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund And the response property "$.code" is "CARRIER_BILLING_REFUND.REFUND_DETAILS_MISMATCH" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature b/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature index 03c760e..617fb97 100644 --- a/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature +++ b/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature @@ -2,7 +2,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema # Input to be provided by the implementation to the tester # # Implementation indications: - # * + # # # Testing assets: # * A phone number eligible for payment & refund @@ -11,7 +11,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml, version 0.1.0 Background: Common retrievePayment setup - Given the resource "/carrier-billing-refund/v0.1/payments/{paymentId}/refunds/remaining-amount" | + Given the resource "/carrier-billing-refund/v0.1/payments/{paymentId}/refunds/remaining-amount" 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 @@ -21,7 +21,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema # Happy path scenarios ############################## - @retrieve_payment_remaining_amount_01_generic_success_scenario Scenario: Common validations for any success scenario Given an existing payment created by operation createPayment OR preparePayment @@ -33,11 +32,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema # 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/PaymentRemainingAmount" - @retrieve_payment_remaining_amount_02_total_refund_in_progress Scenario: Remaining payment amount for total refund in progress Given an existing payment created by operation createPayment OR preparePayment - And an existing total refund being perfomed for that "paymentId" + And an existing total refund being perfomed for that "paymentId" And the path parameter "paymentId" is set to the value for that payment When the HTTP "GET" request is sent Then the response status code is 200 @@ -47,11 +45,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response body complies with the OAS schema at "/components/schemas/PaymentRemainingAmount" And the response property "$.amount" is "0" - @retrieve_payment_remaining_amount_03_total_refund_succeeded Scenario: Remaining payment amount for total refund succeeded Given an existing payment created by operation createPayment OR preparePayment - And an existing total refund completed successfully for that "paymentId" + And an existing total refund completed successfully for that "paymentId" And the path parameter "paymentId" is set to the value for that payment When the HTTP "GET" request is sent Then the response status code is 200 @@ -61,11 +58,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response body complies with the OAS schema at "/components/schemas/PaymentRemainingAmount" And the response property "$.amount" is "0" - @retrieve_payment_remaining_amount_04_total_refund_denied Scenario: Remaining payment amount for total refund denied Given an existing payment created by operation createPayment OR preparePayment - And an existing total refund finally denied for that "paymentId" + And an existing total refund finally denied for that "paymentId" And the path parameter "paymentId" is set to the value for that payment When the HTTP "GET" request is sent Then the response status code is 200 @@ -75,11 +71,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response body complies with the OAS schema at "/components/schemas/PaymentRemainingAmount" And the response property "$.amount" is the value of the amount of the related payment - @retrieve_payment_remaining_amount_05_partial_refund_in_progress Scenario: Remaining payment amount for partial refund in progress Given an existing payment created by operation createPayment OR preparePayment - And an existing partial refund being perfomed for that "paymentId" + And an existing partial refund being perfomed for that "paymentId" And the path parameter "paymentId" is set to the value for that payment When the HTTP "GET" request is sent Then the response status code is 200 @@ -89,11 +84,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response body complies with the OAS schema at "/components/schemas/PaymentRemainingAmount" And the response property "$.amount" is the value of "payment amount" - "refund amount" - @retrieve_payment_remaining_amount_06_partial_refund_succeeded Scenario: Remaining payment amount for partial refund succeeded Given an existing payment created by operation createPayment OR preparePayment - And an existing partial refund completed successfully for that "paymentId" + And an existing partial refund completed successfully for that "paymentId" And the path parameter "paymentId" is set to the value for that payment When the HTTP "GET" request is sent Then the response status code is 200 @@ -103,11 +97,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response body complies with the OAS schema at "/components/schemas/PaymentRemainingAmount" And the response property "$.amount" is the value of "payment amount" - "refund amount" - @retrieve_payment_remaining_amount_07_partial_refund_denied Scenario: Remaining payment amount for partial refund denied Given an existing payment created by operation createPayment OR preparePayment - And an existing partial refund finally denied for that "paymentId" + And an existing partial refund finally denied for that "paymentId" And the path parameter "paymentId" is set to the value for that payment When the HTTP "GET" request is sent Then the response status code is 200 @@ -117,7 +110,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response body complies with the OAS schema at "/components/schemas/PaymentRemainingAmount" And the response property "$.amount" is the value of the amount of the related payment - ############################## # Error scenarios ############################## @@ -134,7 +126,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_payment_remaining_amount_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -145,7 +136,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_payment_remaining_amount_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -157,7 +147,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @retrieve_payment_remaining_amount_403.01_invalid_token_permissions @@ -171,7 +160,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @retrieve_payment_remaining_amount_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -183,7 +171,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - # Error 404 scenarios @retrieve_payment_remaining_amount_404.01_payment_not_found @@ -196,8 +183,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema And the response property "$.code" is "NOT_FOUND" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature b/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature index 46fcc9d..9f8ea92 100644 --- a/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature +++ b/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature @@ -2,7 +2,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund # Input to be provided by the implementation to the tester # # Implementation indications: - # * + # # # Testing assets: # * A phone number eligible for payment & refund @@ -22,7 +22,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund # Happy path scenarios ############################## - @retrieve_refund_01_generic_success_scenario Scenario: Common validations for any success scenario Given an existing refund created by operation createRefund @@ -35,7 +34,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund # 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/Refund" - ############################## # Error scenarios ############################## @@ -53,7 +51,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_refund_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -65,7 +62,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_refund_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -78,7 +74,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @retrieve_refund_403.01_invalid_token_permissions @@ -92,7 +87,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @retrieve_refund_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -105,14 +99,13 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - # Error 404 scenarios @retrieve_refund_404.01_payment_not_found Scenario: Payment not found # To test this, a 2-legged access token is needed, just beacuse if not it triggers test "@retrieve_refund_403.02_phoneNumber_token_mismatch" Given the path parameter "paymentId" is set to a non-existing value in the environment - Given the path parameter "refundId" is set to a valid value in the environment + And the path parameter "refundId" is set to a valid value in the environment And the header "Authorization" is set to a valid access token When the HTTP "POST" request is sent Then the response status code is 404 @@ -120,11 +113,10 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund And the response property "$.code" is "NOT_FOUND" And the response property "$.message" contains a user friendly text - @retrieve_refund_404.02_refund_not_found Scenario: Refund not found Given the path parameter "paymentId" is set to a valid value in the environment - Given the path parameter "refundId" is set to a non-existing value in the environment + And the path parameter "refundId" is set to a non-existing value in the environment And the header "Authorization" is set to a valid access token When the HTTP "POST" request is sent Then the response status code is 404 @@ -132,8 +124,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund And the response property "$.code" is "NOT_FOUND" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature index 8943f7b..d11f21d 100644 --- a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature +++ b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature @@ -2,7 +2,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds # Input to be provided by the implementation to the tester # # Implementation indications: - # * + # # # Testing assets: # * A phone number eligible for payment & refund @@ -11,7 +11,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds # References to OAS spec schemas refer to schemas specifies in carrier-billing-refund.yaml, version 0.1.0 Background: Common retrievePayment setup - Given the resource "/carrier-billing-refund/v0.1/payments/{paymentId}/refunds" + Given the resource "/carrier-billing-refund/v0.1/payments/{paymentId}/refunds" 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 @@ -21,7 +21,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds # Happy path scenarios ############################## - @retrieve_refunds_01_generic_success_scenario Scenario: Common validations for any success scenario Given at least an existing refund created by operation createRefund @@ -32,7 +31,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds # 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/RefundArray" - @retrieve_refunds_02_no_refunds Scenario: No existing refunds Given no refunds have been created by operation createRefund @@ -42,7 +40,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response header "x-correlator" has same value as the request header "x-correlator" And the response body is an empty array "[]" - @retrieve_refunds_03_for_phoneNumber Scenario: List of refunds for a given phone number Given at least an existing refund created by operation createRefund @@ -55,7 +52,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response body complies with the OAS schema at "/components/schemas/RefundArray" And only the refunds associated to that phone number are returned - @retrieve_refunds_04_for_application Scenario: List of refunds for a given application (API client) #To test this scenario, a 2-legged token is needed @@ -69,7 +65,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response body complies with the OAS schema at "/components/schemas/RefundArray" And only the refunds associated to that application are returned - # Query Parameter scenarios @retrieve_refunds_05_start_creationDate @@ -92,7 +87,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds | NOW - 7 days | | NOW - 30 days | - @retrieve_refunds_06_end_creationDate Scenario Outline: List of refunds up to a given creationDate Given several existing refunds created by operation createRefund @@ -106,14 +100,13 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response body complies with the OAS schema at "/components/schemas/RefundArray" And all the refunds returned have their property "$[*].refundCreationDate" <= "" And only the refunds with their property "$[*].refundCreationDate" <= "" are returned - + Examples: | creation_date | | NOW - 1 day | | NOW - 3 days | | NOW - 7 days | - @retrieve_refunds_07_date_range Scenario Outline: List of refunds within a creationDate range Given several existing refunds created by operation createRefund @@ -135,7 +128,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds | NOW - 30 days | NOW | | NOW - 30 days | NOW - 7 days | - @retrieve_refunds_08_ordering Scenario Outline: List of refunds ordered by refundCreationDate Given several existing refunds created by operation createRefund @@ -154,7 +146,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds | desc | | asc | - @retrieve_refunds_09_refund_status Scenario Outline: List of refunds in a given status Given several existing refunds created by operation createRefund in different refund status @@ -172,9 +163,8 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds Examples: | refund_status | | processing | - | denied | - | succeeded | - + | denied | + | succeeded | @retrieve_refunds_10_merchantIdentifier Scenario: List of refunds for a given merchantIdentifier @@ -190,7 +180,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And all the refunds returned have their property "$[*].amountTransaction.refundAmount.chargingMetadata.merchantIdentifier" set to the same value as the query parameter "merchantIdentifier" And only the refunds with their property "$[*].amountTransaction.refundAmount.chargingMetadata.merchantIdentifier" set to the same value as the query parameter "merchantIdentifier" are returned - @retrieve_refunds_11_pagination Scenario: Pagination in List of refunds Given several existing refunds created by operation createRefund, at least more than five @@ -205,7 +194,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response body complies with the OAS schema at "/components/schemas/RefundArray" And only five refunds are returned - ############################## # Error scenarios ############################## @@ -229,7 +217,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds | NOW | NOW - 7 days | | NOW - 7 days | NOW - 30 days | - @retrieve_refunds_400.02_out_of_range Scenario: List of refunds out of range Given several existing refunds created by operation createRefund @@ -242,7 +229,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response property "$.code" is "CARRIER_BILLING_REFUND.OUT_OF_RANGE" And the response property "$.message" contains a user friendly text - @retrieve_refunds_400.03_too_many_matching_records Scenario: List of refunds too many matching records #Optional test to be performed. To test this scenario there would be needed many refunds in the environment. @@ -256,7 +242,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response property "$.code" is "CARRIER_BILLING_REFUND.TOO_MANY_MATCHING_RECORDS" And the response property "$.message" contains a user friendly text - # Error 401 scenarios @retrieve_refunds_401.01_no_authorization_header @@ -268,7 +253,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_refunds_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -278,7 +262,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_refunds_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -289,7 +272,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @retrieve_refunds_403.01_invalid_token_permissions @@ -302,7 +284,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @retrieve_refunds_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained without associated to a phoneNumber @@ -313,7 +294,6 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - ############################## ##END - ############################## \ No newline at end of file + ############################## diff --git a/code/Test_definitions/carrier-billing-retrievePayment.feature b/code/Test_definitions/carrier-billing-retrievePayment.feature index 860e305..2d648e7 100644 --- a/code/Test_definitions/carrier-billing-retrievePayment.feature +++ b/code/Test_definitions/carrier-billing-retrievePayment.feature @@ -2,7 +2,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment # Input to be provided by the implementation to the tester # # Implementation indications: - # * + # # # Testing assets: # * A phone number eligible for payment (no restrictions for it to be used to perform a payment) @@ -11,7 +11,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.3.0 Background: Common retrievePayment setup - Given the resource "/carrier-billing/v0.3/payments/{paymentId}" | + Given the resource "/carrier-billing/v0.3/payments/{paymentId}" 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 @@ -21,7 +21,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment # Happy path scenarios ############################## - @retrieve_payment_01_generic_success_scenario Scenario: Common validations for any success scenario Given an existing payment created by operation createPayment OR preparePayment @@ -33,7 +32,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment # 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/Payment" - ############################## # Error scenarios ############################## @@ -50,7 +48,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_payment_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -61,7 +58,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_payment_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -73,7 +69,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @retrieve_payment_403.01_invalid_token_permissions @@ -87,7 +82,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @retrieve_payment_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained for a different phoneNumber @@ -99,7 +93,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - # Error 404 scenarios @retrieve_payment_404.01_payment_not_found @@ -113,8 +106,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment And the response property "$.code" is "NOT_FOUND" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-retrievePayments.feature b/code/Test_definitions/carrier-billing-retrievePayments.feature index 28345f7..32213f8 100644 --- a/code/Test_definitions/carrier-billing-retrievePayments.feature +++ b/code/Test_definitions/carrier-billing-retrievePayments.feature @@ -2,7 +2,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments # Input to be provided by the implementation to the tester # # Implementation indications: - # * + # # # Testing assets: # * A phone number eligible for payment (no restrictions for it to be used to perform a payment) @@ -11,7 +11,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.3.0 Background: Common retrievePayment setup - Given the resource "/carrier-billing/v0.3/payments" | + Given the resource "/carrier-billing/v0.3/payments" 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 @@ -20,7 +20,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments # Happy path scenarios ############################## - @retrieve_payments_01_generic_success_scenario Scenario: Common validations for any success scenario Given at least an existing payment created by operation createPayment OR preparePayment @@ -31,7 +30,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments # 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/PaymentArray" - @retrieve_payments_02_no_payments Scenario: No existing payments Given no payments have been created by operation createPayment OR preparePayment @@ -41,7 +39,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response header "x-correlator" has same value as the request header "x-correlator" And the response body is an empty array "[]" - @retrieve_payments_03_for_phoneNumber Scenario: List of payments for a given phone number Given at least an existing payment created by operation createPayment OR preparePayment @@ -54,7 +51,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response body complies with the OAS schema at "/components/schemas/PaymentArray" And only the payments associated to that phone number are returned - @retrieve_payments_04_for_application Scenario: List of payments for a given application (API client) #To test this scenario, a 2-legged token is needed @@ -68,7 +64,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response body complies with the OAS schema at "/components/schemas/PaymentArray" And only the payments associated to that application are returned - # Query Parameter scenarios @retrieve_payments_05_start_creationDate @@ -91,7 +86,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments | NOW - 7 days | | NOW - 30 days | - @retrieve_payments_06_end_creationDate Scenario Outline: List of payments up to a given creationDate Given several existing payments created by operation createPayment OR preparePayment @@ -112,7 +106,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments | NOW - 3 days | | NOW - 7 days | - @retrieve_payments_07_date_range Scenario Outline: List of payments within a creationDate range Given several existing payments created by operation createPayment OR preparePayment @@ -134,7 +127,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments | NOW - 30 days | NOW | | NOW - 30 days | NOW - 7 days | - @retrieve_payments_08_ordering Scenario Outline: List of payments ordered by creationPaymentDate Given several existing payments created by operation createPayment OR preparePayment @@ -153,7 +145,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments | desc | | asc | - @retrieve_payments_09_payment_status Scenario Outline: List of payments in a given status Given several existing payments created by operation createPayment OR preparePayment in different payment status @@ -177,7 +168,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments | succeeded | | cancelled | - @retrieve_payments_10_merchantIdentifier Scenario: List of payments for a given merchantIdentifier Given several existing payments created by operation createPayment OR preparePayment for a given merchant @@ -192,7 +182,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And all the payments returned have their property "$.amountTransaction.paymentAmount.chargingMetadata.merchantIdentifier" set to the same value as the query parameter "merchantIdentifier" And only the payments with their property "$.amountTransaction.paymentAmount.chargingMetadata.merchantIdentifier" set to the same value as the query parameter "merchantIdentifier" are returned - @retrieve_payments_11_pagination Scenario: Pagination in List of payments Given several existing payments created by operation createPayment OR preparePayment, at least more than five @@ -207,7 +196,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response body complies with the OAS schema at "/components/schemas/PaymentArray" And only five payments returned - ############################## # Error scenarios ############################## @@ -231,7 +219,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments | NOW | NOW - 7 days | | NOW - 7 days | NOW - 30 days | - @retrieve_payments_400.02_out_of_range Scenario: List of payments out of range Given several existing payments created by operation createPayment OR preparePayment @@ -244,7 +231,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response property "$.code" is "CARRIER_BILLING.OUT_OF_RANGE" And the response property "$.message" contains a user friendly text - @retrieve_payments_400.03_too_many_matching_records Scenario: List of payments too many matching records #Optional test to be performed. To test this scenario there would be needed many payments in the environment. @@ -258,7 +244,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response property "$.code" is "CARRIER_BILLING.TOO_MANY_MATCHING_RECORDS" And the response property "$.message" contains a user friendly text - # Error 401 scenarios @retrieve_payments_401.01_no_authorization_header @@ -270,7 +255,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_payments_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -280,7 +264,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @retrieve_payments_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -291,7 +274,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @retrieve_payment_403.01_invalid_token_permissions @@ -304,7 +286,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - @retrieve_payment_403.02_phoneNumber_token_mismatch Scenario: Inconsistent access token context for the phoneNumber # To test this, a 3-legged access token has to be obtained without associated to a phoneNumber @@ -315,8 +296,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response property "$.code" is "INVALID_TOKEN_CONTEXT" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - diff --git a/code/Test_definitions/carrier-billing-validatePayment.feature b/code/Test_definitions/carrier-billing-validatePayment.feature index 311b904..fd8eede 100644 --- a/code/Test_definitions/carrier-billing-validatePayment.feature +++ b/code/Test_definitions/carrier-billing-validatePayment.feature @@ -2,15 +2,15 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment # Input to be provided by the implementation to the tester # # Implementation indications: - # * Optional endpoint in a 2-step payment just only used in case a validation step is needed between reservation and commitment of the payment - # + # * Optional endpoint in a 2-step payment just only used in case a validation step is needed between reservation and commitment of the payment + # # Testing assets: # * N/A (so far) # # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.3.0 Background: Common validatePayment setup - Given the resource "/carrier-billing/v0.3/payments/{paymentId}/validate" | + Given the resource "/carrier-billing/v0.3/payments/{paymentId}/validate" 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 @@ -21,7 +21,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment # Happy path scenarios ############################## - @validate_payment_01_generic_success_scenario Scenario: Common validations for any success scenario # Valid default request body compliant with the schema @@ -33,12 +32,10 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response header "Content-Type" is "application/json" And the response header "x-correlator" has same value as the request header "x-correlator" - ############################## # Error scenarios ############################## - # Error 400 scenarios @validate_payment_400.01_no_request_body @@ -50,7 +47,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text - @validate_payment_400.02_empty_request_body Scenario: Empty object as request body Given the request body is set to "{}" @@ -60,7 +56,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text | - @validate_payment_400.03_required_input_properties_missing Scenario Outline: Required input properties are missing Given the request body property "" is not included @@ -75,7 +70,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment | $.authorizationId | | $.code | - @validate_payment_400.04_invalid_authorizationId Scenario: Using a invalid authorizationId value Given the request body property includes property "$.authorizationId" with a non-existing value in the environment @@ -85,7 +79,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "CARRIER_BILLING.INVALID_AUTHORIZATION_ID" And the response property "$.message" contains a user friendly text - @validate_payment_400.05_invalid_code Scenario: Using a invalid code value Given the request body property includes property "$.code" with a non-existing value in the environment @@ -95,7 +88,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "CARRIER_BILLING.INVALID_CODE" And the response property "$.message" contains a user friendly text - @validate_payment_400.06_exceeding_validation attempts # Variable "N" can vary up to Telco Operator policies Scenario outline: Using a invalid code value after N requests @@ -111,7 +103,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment | 3 | | 5 | - # Error 401 scenarios @validate_payment_01_generic_success_scenario_payment_401.01_no_authorization_header @@ -124,7 +115,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @validate_payment_401.02_expired_access_token Scenario: Expired access token Given the header "Authorization" is set to an expired access token @@ -135,7 +125,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - @validate_payment_401.03_invalid_access_token Scenario: Invalid access token Given the header "Authorization" is set to an invalid access token @@ -147,7 +136,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "UNAUTHENTICATED" And the response property "$.message" contains a user friendly text - # Error 403 scenarios @validate_payment_403.01_invalid_token_permissions @@ -161,8 +149,6 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment And the response property "$.code" is "PERMISSION_DENIED" And the response property "$.message" contains a user friendly text - ############################## ##END ############################## - From 8cb48844dda22cf6a7628192e25c1bdbdde5ec4d Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 20:55:56 +0100 Subject: [PATCH 02/11] add_gherkin_linter_configuration --- .gherkin-lintrc | 74 ++++++++++++++++++++++++++++++++ .github/workflows/megalinter.yml | 4 ++ 2 files changed, 78 insertions(+) create mode 100644 .gherkin-lintrc diff --git a/.gherkin-lintrc b/.gherkin-lintrc new file mode 100644 index 0000000..c832c90 --- /dev/null +++ b/.gherkin-lintrc @@ -0,0 +1,74 @@ +{ + "no-files-without-scenarios" : "on", + "no-unnamed-features": "on", + "no-unnamed-scenarios": "on", + "no-dupe-scenario-names": ["on", "in-feature"], + "no-dupe-feature-names": "on", + "no-partially-commented-tag-lines": "on", + "indentation" : [ + "on", { + "Feature": 0, + "Background": 0, + "Scenario": 2, + "Step": 2, + "Examples": 4, + "example": 4, + "given": 4, + "when": 4, + "then": 4, + "and": 4, + "but": 4, + "feature tag": 2, + "scenario tag": 2 + } + ], + "no-trailing-spaces": "on", + "new-line-at-eof": ["on", "no"], + "no-multiple-empty-lines": "on", + "no-empty-file": "on", + "no-scenario-outlines-without-examples": "on", + "name-length": ["on", {"Feature": 90, "Step": 190, "Scenario": 190}], + "no-restricted-tags": ["on", {"tags": ["@watch", "@wip"]}], + "use-and": "on", + "keywords-in-logical-order": "on", + "no-duplicate-tags": "on", + "no-superfluous-tags": "on", + "no-homogenous-tags": "on", + "one-space-between-tags": "on", + "no-unused-variables": "on", + "no-background-only-scenario": "on", + "no-empty-background": "on", + "scenario-size": ["on", { "steps-length": {"Background": 15, "Scenario": 15}}], + "only-one-when": "off", + "allowed-tags": ["on", { + "patterns": [ + "^@watch$", + "^@wip$", + "^@.*$" + ] + }], + "file-name": ["on", {"style": "kebab-case"}], + "max-scenarios-per-file": ["on", {"maxScenarios": 50, "countOutlineExamples": true}], + "no-restricted-patterns": ["on", { + "Global": [ + "^globally restricted pattern" + ], + "Feature": [ + "poor description", + "validate", + "verify" + ], + "Background": [ + "show last response", + "a debugging step" + ], + "Scenario": [ + "show last response", + "a debugging step" + ] + }], + "required-tags": ["on", { + "tags": ["^@.*$"], // Allow any tag starting with '@' + "ignoreUntagged": false // Enforce tagging +}] +} diff --git a/.github/workflows/megalinter.yml b/.github/workflows/megalinter.yml index 6bda700..db9debe 100644 --- a/.github/workflows/megalinter.yml +++ b/.github/workflows/megalinter.yml @@ -42,6 +42,10 @@ jobs: run: npm install -g @stoplight/spectral - name: Install Spectral functions run: npm install -g @stoplight/spectral-functions + - name: Install Gherkin Linter + run: npm install -g gherkin-lint + - name: Run Gherkin Linting + run: gherkin-lint code/Test_definitions/*.feature # - name: Run spectral:oas Spectral Linting # run: spectral lint code/API_definitions/*.yaml --verbose --ruleset .spectral.yml # Replace openapi.yaml file with your API specification file From b682ea064a19f5adaff14416ea610e8acf1b4950 Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 21:08:38 +0100 Subject: [PATCH 03/11] first_set_of_changes_for_linter --- code/Test_definitions/carrier-billing-cancelPayment.feature | 2 +- .../Test_definitions/carrier-billing-confirmPayment.feature | 2 +- code/Test_definitions/carrier-billing-createPayment.feature | 6 +++--- .../Test_definitions/carrier-billing-preparePayment.feature | 2 +- .../carrier-billing-refund-createRefund.feature | 2 +- ...er-billing-refund-retrievePaymentRemainingAmount.feature | 2 +- .../carrier-billing-refund-retrieveRefund.feature | 2 +- .../carrier-billing-refund-retrieveRefunds.feature | 2 +- .../carrier-billing-retrievePayment.feature | 2 +- .../carrier-billing-retrievePayments.feature | 2 +- .../carrier-billing-validatePayment.feature | 2 +- 11 files changed, 13 insertions(+), 13 deletions(-) diff --git a/code/Test_definitions/carrier-billing-cancelPayment.feature b/code/Test_definitions/carrier-billing-cancelPayment.feature index fdce2cc..2d1f18c 100644 --- a/code/Test_definitions/carrier-billing-cancelPayment.feature +++ b/code/Test_definitions/carrier-billing-cancelPayment.feature @@ -168,4 +168,4 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-confirmPayment.feature b/code/Test_definitions/carrier-billing-confirmPayment.feature index fd4f7b3..d509df6 100644 --- a/code/Test_definitions/carrier-billing-confirmPayment.feature +++ b/code/Test_definitions/carrier-billing-confirmPayment.feature @@ -180,4 +180,4 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-createPayment.feature b/code/Test_definitions/carrier-billing-createPayment.feature index 19e00c8..b93eece 100644 --- a/code/Test_definitions/carrier-billing-createPayment.feature +++ b/code/Test_definitions/carrier-billing-createPayment.feature @@ -3,7 +3,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment # # Implementation indications: # * Telco Operator carrier billing behaviour mode: sync or async - # + # # Testing assets: # * A phone number eligible for payment (no restrictions for it to be used to perform a payment) # * A phone number not-eligible for payment (payment is denied for it due to business conditions) @@ -11,7 +11,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.3.0 Background: Common createPayment setup - Given the resource "/carrier-billing/v0.3/payments" | + Given the resource "/carrier-billing/v0.3/payments" 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 @@ -395,4 +395,4 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-preparePayment.feature b/code/Test_definitions/carrier-billing-preparePayment.feature index f990362..e2edbe9 100644 --- a/code/Test_definitions/carrier-billing-preparePayment.feature +++ b/code/Test_definitions/carrier-billing-preparePayment.feature @@ -408,4 +408,4 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-refund-createRefund.feature b/code/Test_definitions/carrier-billing-refund-createRefund.feature index e951cf2..a89ddeb 100644 --- a/code/Test_definitions/carrier-billing-refund-createRefund.feature +++ b/code/Test_definitions/carrier-billing-refund-createRefund.feature @@ -457,4 +457,4 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature b/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature index 617fb97..1e9fefd 100644 --- a/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature +++ b/code/Test_definitions/carrier-billing-refund-retrievePaymentRemainingAmount.feature @@ -185,4 +185,4 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrievePaymentRema ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature b/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature index 9f8ea92..3fb193a 100644 --- a/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature +++ b/code/Test_definitions/carrier-billing-refund-retrieveRefund.feature @@ -126,4 +126,4 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefund ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature index d11f21d..d1bc442 100644 --- a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature +++ b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature @@ -296,4 +296,4 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-retrievePayment.feature b/code/Test_definitions/carrier-billing-retrievePayment.feature index 2d648e7..3e5c64b 100644 --- a/code/Test_definitions/carrier-billing-retrievePayment.feature +++ b/code/Test_definitions/carrier-billing-retrievePayment.feature @@ -108,4 +108,4 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayment ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-retrievePayments.feature b/code/Test_definitions/carrier-billing-retrievePayments.feature index 32213f8..70f77d2 100644 --- a/code/Test_definitions/carrier-billing-retrievePayments.feature +++ b/code/Test_definitions/carrier-billing-retrievePayments.feature @@ -298,4 +298,4 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments ############################## ##END - ############################## + ############################## \ No newline at end of file diff --git a/code/Test_definitions/carrier-billing-validatePayment.feature b/code/Test_definitions/carrier-billing-validatePayment.feature index fd8eede..11dfbf3 100644 --- a/code/Test_definitions/carrier-billing-validatePayment.feature +++ b/code/Test_definitions/carrier-billing-validatePayment.feature @@ -151,4 +151,4 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment ############################## ##END - ############################## + ############################## \ No newline at end of file From cd44fa4e39cc18a046c76d8b0cf6483c714e8eb2 Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 21:10:44 +0100 Subject: [PATCH 04/11] update_gherkin_linter --- .gherkin-lintrc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.gherkin-lintrc b/.gherkin-lintrc index c832c90..ba62b34 100644 --- a/.gherkin-lintrc +++ b/.gherkin-lintrc @@ -8,7 +8,7 @@ "indentation" : [ "on", { "Feature": 0, - "Background": 0, + "Background": 2, //CHANGED: From "0" to "2". Should BE of level "2" "Scenario": 2, "Step": 2, "Examples": 4, @@ -47,7 +47,7 @@ "^@.*$" ] }], - "file-name": ["on", {"style": "kebab-case"}], + "file-name": ["off", {"style": "kebab-case"}], //DISABLED ("on" -> "off"): As per ATP testing guidelines, the `operationId` can be part of the test file and `operationId` follow lowerCamelCase format "max-scenarios-per-file": ["on", {"maxScenarios": 50, "countOutlineExamples": true}], "no-restricted-patterns": ["on", { "Global": [ From ba2eeb5ea84ba2cca212b7b756a262281ff35be8 Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 21:22:12 +0100 Subject: [PATCH 05/11] second_set_of_changes_for_linter --- .gherkin-lintrc | 2 +- .../carrier-billing-createPayment.feature | 6 +++--- .../carrier-billing-refund-createRefund.feature | 2 +- .../carrier-billing-retrievePayments.feature | 10 +++++----- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/.gherkin-lintrc b/.gherkin-lintrc index ba62b34..1d90cda 100644 --- a/.gherkin-lintrc +++ b/.gherkin-lintrc @@ -12,7 +12,7 @@ "Scenario": 2, "Step": 2, "Examples": 4, - "example": 4, + "example": 6, //CHANGED: From "4" to "6". Should BE of level "6" to have more indentation that the "Examples" umbrella "given": 4, "when": 4, "then": 4, diff --git a/code/Test_definitions/carrier-billing-createPayment.feature b/code/Test_definitions/carrier-billing-createPayment.feature index b93eece..dca4def 100644 --- a/code/Test_definitions/carrier-billing-createPayment.feature +++ b/code/Test_definitions/carrier-billing-createPayment.feature @@ -112,7 +112,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment And the response body property "$.amountTransaction.paymentAmount.chargingMetaData.merchantIdentifier" has the same value as provided in the request body @create_payment_08_amountTransaction_paymentDetails - Scenario: Request 1-step payment indicating merchantIdentifier + Scenario: Request 1-step payment indicating paymentDetails Given the request body property "$.amountTransaction" is set with valid required information And the request body array property "$.amountTransaction.paymentAmount.paymentDetails" is set with valid information When the HTTP "POST" request is sent @@ -136,7 +136,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment @create_payment_10_amountTransaction_phoneNumber_three_legged # Case using a 3-legged Access Token emitted for a specific phone number - Scenario: Request 1-step payment indicating phoneNumber + Scenario: Request 1-step payment indicating phoneNumber in 3-legged access mode Given the request body property "$.amountTransaction" is set with valid required information And the request body property "$.amountTransaction.phoneNumber" is set to a valid value which is the same as associated to access token When the HTTP "POST" request is sent @@ -148,7 +148,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation createPayment @create_payment_11_amountTransaction_phoneNumber_two_legged # Case using a 2-legged Access Token. Only applicable for Countries and Telco Operators whose regulation allows for it - Scenario: Request 1-step payment indicating phoneNumber + Scenario: Request 1-step payment indicating phoneNumber in 2-legged access mode Given the request body property "$.amountTransaction" is set with valid required information And the request body property "$.amountTransaction.phoneNumber" is set to a valid value When the HTTP "POST" request is sent diff --git a/code/Test_definitions/carrier-billing-refund-createRefund.feature b/code/Test_definitions/carrier-billing-refund-createRefund.feature index a89ddeb..e3ad3ec 100644 --- a/code/Test_definitions/carrier-billing-refund-createRefund.feature +++ b/code/Test_definitions/carrier-billing-refund-createRefund.feature @@ -232,7 +232,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund Examples: | input_property | oas_spec_schema | | $.sink | /components/schemas/CreateRefund | - | $.sinkCredential | /components/schemas/SinkCredential | | + | $.sinkCredential | /components/schemas/SinkCredential | @create_refunds_400.04_required_input_properties_missing Scenario Outline: Required input properties are missing diff --git a/code/Test_definitions/carrier-billing-retrievePayments.feature b/code/Test_definitions/carrier-billing-retrievePayments.feature index 70f77d2..162283b 100644 --- a/code/Test_definitions/carrier-billing-retrievePayments.feature +++ b/code/Test_definitions/carrier-billing-retrievePayments.feature @@ -156,16 +156,16 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/PaymentArray" - And all the payments returned have their property "$.paymentStatus" == "" - And only the payments with their property "$.paymentStatus" == "" are returned + And all the payments returned have their property "$.paymentStatus" == "" + And only the payments with their property "$.paymentStatus" == "" are returned Examples: | payment_status | | processing | | pending_validation | - | denied | - | reserved | - | succeeded | + | denied | + | reserved | + | succeeded | | cancelled | @retrieve_payments_10_merchantIdentifier From dfbb4c41737bf18900ecd73a3ecc016652593ab1 Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 21:32:39 +0100 Subject: [PATCH 06/11] third_set_of_changes_for_linter --- .gherkin-lintrc | 2 +- .../carrier-billing-refund-createRefund.feature | 2 +- code/Test_definitions/carrier-billing-validatePayment.feature | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.gherkin-lintrc b/.gherkin-lintrc index 1d90cda..1b244bf 100644 --- a/.gherkin-lintrc +++ b/.gherkin-lintrc @@ -12,7 +12,7 @@ "Scenario": 2, "Step": 2, "Examples": 4, - "example": 6, //CHANGED: From "4" to "6". Should BE of level "6" to have more indentation that the "Examples" umbrella + "example": 6, //CHANGED: From "4" to "6". Should BE of level "6" to have more indentation than the "Examples" umbrella "given": 4, "when": 4, "then": 4, diff --git a/code/Test_definitions/carrier-billing-refund-createRefund.feature b/code/Test_definitions/carrier-billing-refund-createRefund.feature index e3ad3ec..ebb16c6 100644 --- a/code/Test_definitions/carrier-billing-refund-createRefund.feature +++ b/code/Test_definitions/carrier-billing-refund-createRefund.feature @@ -99,7 +99,7 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation createRefund @create_refunds_05_partial_refund_amountTransaction_net_amount Scenario: Request partial refund with net amount - Given the request body property "$.type" is set to "partial" + Given the request body property "$.type" is set to "partial" And the request body property "$.amountTransaction" is set with valid required information for this refund type And the request body property "$.amountTransaction.refundAmount.chargingInformation.isTaxIncluded" is set to false OR not set When the HTTP "POST" request is sent diff --git a/code/Test_definitions/carrier-billing-validatePayment.feature b/code/Test_definitions/carrier-billing-validatePayment.feature index 11dfbf3..3418c26 100644 --- a/code/Test_definitions/carrier-billing-validatePayment.feature +++ b/code/Test_definitions/carrier-billing-validatePayment.feature @@ -54,7 +54,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment 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 | + And the response property "$.message" contains a user friendly text @validate_payment_400.03_required_input_properties_missing Scenario Outline: Required input properties are missing @@ -90,7 +90,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation validatePayment @validate_payment_400.06_exceeding_validation attempts # Variable "N" can vary up to Telco Operator policies - Scenario outline: Using a invalid code value after N requests + Scenario Outline: Using a invalid code value after N requests Given the request body property includes property "$.code" with a non-existing value in the environment When the HTTP "POST" request is sent after "" times Then the response status code is 400 From 5d484350023de30ac4d128cea7cc40fc60902932 Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 21:37:02 +0100 Subject: [PATCH 07/11] specific_change_in_linter_rule_for_carrier_billing --- .gherkin-lintrc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gherkin-lintrc b/.gherkin-lintrc index 1b244bf..6fd53aa 100644 --- a/.gherkin-lintrc +++ b/.gherkin-lintrc @@ -55,7 +55,7 @@ ], "Feature": [ "poor description", - "validate", +// "validate", //DISABLED: Specifically for Carrier Billing as there is an operation named validatePayment "verify" ], "Background": [ From 60a3e545e8faa553be5f6311f32845d67fafb895 Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 21:44:57 +0100 Subject: [PATCH 08/11] fourth_set_of_changes_for_linter --- code/Test_definitions/carrier-billing-cancelPayment.feature | 2 +- code/Test_definitions/carrier-billing-confirmPayment.feature | 2 +- code/Test_definitions/carrier-billing-preparePayment.feature | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/code/Test_definitions/carrier-billing-cancelPayment.feature b/code/Test_definitions/carrier-billing-cancelPayment.feature index 2d1f18c..0a8c59c 100644 --- a/code/Test_definitions/carrier-billing-cancelPayment.feature +++ b/code/Test_definitions/carrier-billing-cancelPayment.feature @@ -10,7 +10,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation cancelPayment # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.3.0 Background: Common cancelPayment setup - Given the resource "/carrier-billing/v0.3/payments/{paymentId}/cancel" | + Given the resource "/carrier-billing/v0.3/payments/{paymentId}/cancel" And the header "Content-Type" is set to "application/json" And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/carrier-billing-confirmPayment.feature b/code/Test_definitions/carrier-billing-confirmPayment.feature index d509df6..0628a6d 100644 --- a/code/Test_definitions/carrier-billing-confirmPayment.feature +++ b/code/Test_definitions/carrier-billing-confirmPayment.feature @@ -11,7 +11,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation confirmPayment # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.3.0 Background: Common confirmPayment setup - Given the resource "/carrier-billing/v0.3/payments/{paymentId}/confirm" | + Given the resource "/carrier-billing/v0.3/payments/{paymentId}/confirm" And the header "Content-Type" is set to "application/json" And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value diff --git a/code/Test_definitions/carrier-billing-preparePayment.feature b/code/Test_definitions/carrier-billing-preparePayment.feature index e2edbe9..21e1f20 100644 --- a/code/Test_definitions/carrier-billing-preparePayment.feature +++ b/code/Test_definitions/carrier-billing-preparePayment.feature @@ -11,7 +11,7 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation preparePayment # References to OAS spec schemas refer to schemas specifies in carrier-billing.yaml, version 0.3.0 Background: Common preparePayment setup - Given the resource "/carrier-billing/v0.3/payments/prepare" | + Given the resource "/carrier-billing/v0.3/payments/prepare" And the header "Content-Type" is set to "application/json" And the header "Authorization" is set to a valid access token And the header "x-correlator" is set to a UUID value From 629ce2ff7a03c3e509790e8a2bdbe2113700f071 Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 22:36:35 +0100 Subject: [PATCH 09/11] test --- .../carrier-billing-refund-retrieveRefunds.feature | 4 ++-- .../Test_definitions/carrier-billing-retrievePayments.feature | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature index d1bc442..7ea2958 100644 --- a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature +++ b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature @@ -98,8 +98,8 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/RefundArray" - And all the refunds returned have their property "$[*].refundCreationDate" <= "" - And only the refunds with their property "$[*].refundCreationDate" <= "" are returned + And all the refunds returned have their property "$[*].refundCreationDate" =< "" + And only the refunds with their property "$[*].refundCreationDate" =< "" are returned Examples: | creation_date | diff --git a/code/Test_definitions/carrier-billing-retrievePayments.feature b/code/Test_definitions/carrier-billing-retrievePayments.feature index 162283b..4a1fd50 100644 --- a/code/Test_definitions/carrier-billing-retrievePayments.feature +++ b/code/Test_definitions/carrier-billing-retrievePayments.feature @@ -97,8 +97,8 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/PaymentArray" - And all the payments returned have their property "$.paymentCreationDate" <= "" - And only the payments with their property "$.paymentCreationDate" <= "" are returned + And all the payments returned have their property "$.paymentCreationDate" =< "" + And only the payments with their property "$.paymentCreationDate" =< "" are returned Examples: | creation_date | From 9d7cf8dbcf9ec71aa121ad651916d80396b0e43d Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Tue, 12 Nov 2024 22:42:13 +0100 Subject: [PATCH 10/11] undo_test --- .../carrier-billing-refund-retrieveRefunds.feature | 4 ++-- .../Test_definitions/carrier-billing-retrievePayments.feature | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature index 7ea2958..d1bc442 100644 --- a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature +++ b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature @@ -98,8 +98,8 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/RefundArray" - And all the refunds returned have their property "$[*].refundCreationDate" =< "" - And only the refunds with their property "$[*].refundCreationDate" =< "" are returned + And all the refunds returned have their property "$[*].refundCreationDate" <= "" + And only the refunds with their property "$[*].refundCreationDate" <= "" are returned Examples: | creation_date | diff --git a/code/Test_definitions/carrier-billing-retrievePayments.feature b/code/Test_definitions/carrier-billing-retrievePayments.feature index 4a1fd50..162283b 100644 --- a/code/Test_definitions/carrier-billing-retrievePayments.feature +++ b/code/Test_definitions/carrier-billing-retrievePayments.feature @@ -97,8 +97,8 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/PaymentArray" - And all the payments returned have their property "$.paymentCreationDate" =< "" - And only the payments with their property "$.paymentCreationDate" =< "" are returned + And all the payments returned have their property "$.paymentCreationDate" <= "" + And only the payments with their property "$.paymentCreationDate" <= "" are returned Examples: | creation_date | From 9a463368c666135427300cf58e28c84b87c7e79a Mon Sep 17 00:00:00 2001 From: PEDRO DIEZ GARCIA Date: Wed, 13 Nov 2024 17:37:31 +0100 Subject: [PATCH 11/11] workaround_for_logical_operators_comparison --- .../carrier-billing-refund-retrieveRefunds.feature | 8 ++++---- .../carrier-billing-retrievePayments.feature | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature index d1bc442..b5b7fac 100644 --- a/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature +++ b/code/Test_definitions/carrier-billing-refund-retrieveRefunds.feature @@ -78,8 +78,8 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/RefundArray" - And all the refunds returned have their property "$[*].refundCreationDate" >= "" - And only the refunds with their property "$[*].refundCreationDate" >= "" are returned + And all the refunds returned have their property "$[*].refundCreationDate" greater or equal than "" + And only the refunds with their property "$[*].refundCreationDate" greater or equal than "" are returned Examples: | creation_date | @@ -98,8 +98,8 @@ Feature: CAMARA Carrier Billing Refund API, v0.1 - Operation retrieveRefunds And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/RefundArray" - And all the refunds returned have their property "$[*].refundCreationDate" <= "" - And only the refunds with their property "$[*].refundCreationDate" <= "" are returned + And all the refunds returned have their property "$[*].refundCreationDate" lower or equal than "" + And only the refunds with their property "$[*].refundCreationDate" lower or equal than "" are returned Examples: | creation_date | diff --git a/code/Test_definitions/carrier-billing-retrievePayments.feature b/code/Test_definitions/carrier-billing-retrievePayments.feature index 162283b..31448ec 100644 --- a/code/Test_definitions/carrier-billing-retrievePayments.feature +++ b/code/Test_definitions/carrier-billing-retrievePayments.feature @@ -77,8 +77,8 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/PaymentArray" - And all the payments returned have their property "$.paymentCreationDate" >= "" - And only the payments with their property "$.paymentCreationDate" >= "" are returned + And all the payments returned have their property "$.paymentCreationDate" greater or equal than "" + And only the payments with their property "$.paymentCreationDate" greater or equal than "" are returned Examples: | creation_date | @@ -97,8 +97,8 @@ Feature: CAMARA Carrier Billing API, v0.3 - Operation retrievePayments And the response header "x-correlator" has same value as the request header "x-correlator" # The response has to comply with the generic response schema which is part of the spec And the response body complies with the OAS schema at "/components/schemas/PaymentArray" - And all the payments returned have their property "$.paymentCreationDate" <= "" - And only the payments with their property "$.paymentCreationDate" <= "" are returned + And all the payments returned have their property "$.paymentCreationDate" lower or equal than "" + And only the payments with their property "$.paymentCreationDate" lower or equal than "" are returned Examples: | creation_date |