diff --git a/.gherkin-lintrc b/.gherkin-lintrc new file mode 100644 index 0000000..6fd53aa --- /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": 2, //CHANGED: From "0" to "2". Should BE of level "2" + "Scenario": 2, + "Step": 2, + "Examples": 4, + "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, + "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": ["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": [ + "^globally restricted pattern" + ], + "Feature": [ + "poor description", +// "validate", //DISABLED: Specifically for Carrier Billing as there is an operation named validatePayment + "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 diff --git a/code/Test_definitions/carrier-billing-cancelPayment.feature b/code/Test_definitions/carrier-billing-cancelPayment.feature index adb0b8d..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 @@ -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 - ############################## - + ############################## \ 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 c6e8f17..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 @@ -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 - ############################## - + ############################## \ 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 d547515..dca4def 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 @@ -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,9 +111,8 @@ 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 + 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 @@ -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,10 +134,9 @@ 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 + 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 @@ -156,10 +146,9 @@ 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 + 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 @@ -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 - ############################## - + ############################## \ 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 e24b679..21e1f20 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) @@ -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 @@ -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 - ############################## - + ############################## \ 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 4e21e1e..ebb16c6 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,10 +97,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 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" + 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 @@ -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 @@ -248,8 +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 @@ -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 - ############################## - + ############################## \ 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 03c760e..1e9fefd 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 - ############################## - + ############################## \ 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 46fcc9d..3fb193a 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 - ############################## - + ############################## \ 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 8943f7b..b5b7fac 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 @@ -83,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 | @@ -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 @@ -104,16 +98,15 @@ 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 | | 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..3e5c64b 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 - ############################## - + ############################## \ 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 28345f7..31448ec 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 @@ -82,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 | @@ -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 @@ -103,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 | @@ -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 @@ -165,19 +156,18 @@ 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 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 - ############################## - + ############################## \ 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 311b904..3418c26 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 "{}" @@ -58,8 +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 @@ -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,10 +88,9 @@ 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 + 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 @@ -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 - ############################## - + ############################## \ No newline at end of file