Create Gherkin tests for device-status-reachability and device-status-roaming

[mdomale]

Feature file for device-reachability-status & device-roaming-status

What type of PR is this?

• tests

What this PR does / why we need it:

Gherkin syntax feature file for syntax

Which issue(s) this PR fixes:

Fixes #

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[bigludo7]

Hello @mdomale
Thanks for the contribution.
Probably better to split in 2 files to have one file for device-reachability-status and another for device-connectivity-status.

On the file itself we should align with the API-Testing-Guidelines. We should have environment variables, background section, etc... You can probably take a look on this PR that could be used as an illustration of the guidelines.

[mdomale]

Updated as per newly agreed camara testing guidelines

[bigludo7]

Thanks for the contribution.

Few suggestions for your appreciation. I did the review for code/Test_definitions/device-reachability-status.feature but I guess same applies for the second API.

• Add Test cases for 403 INVALID_TOKEN_CONTEXT

  Scenario: Inconsistent access token context for the device
    # To test this, a token have to be obtained for a different device
    Given the request body property "$.device" is set to a valid testing device
    And the header "Authorization" is set to a valid access token emitted for a different device
    When the HTTP "POST" request is sent
    Then the response status code is 403
    And the response property "$.status" is 403
    And the response property "$.code" is "INVALID_TOKEN_CONTEXT"
    And the response property "$.message" contains a user friendly text

• Add Test Case for 422 for DEVICE_IDENTIFIERS_MISMATCH

  Scenario: Device identifiers mismatch
    # To test this, at least 2 types of identifiers have to be provided, e.g. a phoneNumber and the IP address of a device associated to a different phoneNumber
    Given that config_var "identifier_types_unsupported" contains at least 2 items
    And the request body property "$.device" includes several identifiers, each of them identifying a valid but different device
    When the HTTP "POST" request is sent
    Then the response status code is 422
    And the response property "$.status" is 422
    And the response property "$.code" is "DEVICE_IDENTIFIERS_MISMATCH"
    And the response property "$.message" contains a user friendly text

• Add Test Case for 422 for DEVICE_NOT_APPLICABLE

  Scenario: Service not available for the device
    Given that service is not supported for all devices commercialized by the operator 
    And the request body property "$.device" is set to a valid device for which the service is not applicable
    When the HTTP "POST" request is sent
    Then the response status code is 422
    And the response property "$.status" is 422
    And the response property "$.code" is "DEVICE_NOT_APPLICABLE"
    And the response property "$.message" contains a user friendly text

• Add Test Case for 422 for UNABLE_TO_PROVIDE_REACHABILITY_STATUS

• We can add one for 406 but not very valuable - I'm fine if you skip this one.

[bigludo7]

@mdomale @akoshunyadi
It looks very good for me.

For me oly one thing missing: all explicit error are not tested. You have added 422 DEVICE_IDENTIFIERS_MISMATCH. We should also add test cased for 422 DEVICE_NOT_APPLICABLE, 422 UNABLE_TO_PROVIDE_REACHABILITY_STATUS and 422 UNSUPPORTED_DEVICE_IDENTIFIERS

Then for me we will be good !
Thanks

[mdomale]

@bigludo7 @sachinvodafone PR amended. Kindly review

[bigludo7]

Thanks @mdomale
I saw you added the 3 422 so it is good for me !

[mdomale]

@bigludo7 @bigludo7 PR updated .

[bigludo7]

lgtm