Test definition location retrieval

[bigludo7]

What type of PR is this?

Add one of the following kinds:

• tests

What this PR does / why we need it:

Provide test definition for Location-retrieval

Which issue(s) this PR fixes:

Fixes #196

Special notes for reviewers:

I got an issue with my previous PR #119 so I have to create a new one :(

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.02s
✅ OPENAPI	spectral	3		0	4.83s
✅ REPOSITORY	git_diff	yes		no	0.01s
✅ REPOSITORY	secretlint	yes		no	0.81s
✅ YAML	yamllint	3		0	0.74s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[trehman-gsma]

Will this 404 case be possible in three-legged token use cases? The access token would be tied to a valid device already?

[bigludo7]

As for 400.4 TC this is a borderline TC. See my comment below and I guess we could apply same decision.

[jlurien]

There may be situations as @bigludo7 suggests when the access token is valid but the device included in the request does not point to any device.

• Device can NOT be deducted from the access token:
  • device NOT included in the request body-> 422 UNIDENTIFIABLE_DEVICE
  • device included in the request body but not pointing to a known device -> 404 DEVICE_NOT_FOUND

[trehman-gsma]

What do you think about one more test case to validate the maxAge minimum value compliance (minimum=60)?

It could either be combined with this test case (@location_retrieval_400.3_max_age_schema_compliant) or it could be a new test case. Examples below.

Combining into one:

@location_retrieval_400.3_max_age_schema_compliant
Scenario: maxAge value does not comply with the schema
    Given the request body property "$.device" is set to a valid testing device
    And the request body property "maxAge" does not comply with the OAS schema at "/components/schemas/RetrievalLocationRequest" 
    When the HTTP "POST" request is sent
    Then the response status code is 400
    And the response property "$.status" is 400
    And the response property "$.code" is "INVALID_ARGUMENT"
    And the response property "$.message" contains a user friendly text

    Examples:
      | maxAge  |
      | 6a0     |
      | 59      |

Creating a separate use case:

@location_retrieval_400.4_max_age_min_schema_compliant
Scenario: maxAge value is below the minimum (60) allowed
    Given the request body property "$.device" is set to a valid testing device
    And the "maxAge" is set to 59
    When the HTTP "POST" request is sent
    Then the response status code is 400
    And the response property "$.status" is 400
    And the response property "$.code" is "INVALID_ARGUMENT"
    And the response property "$.message" contains a user friendly text

[bigludo7]

@trehman-gsma we have removed the maxAge limitation. You can omit it or pass it with 0 value as well.

[trehman-gsma]

oh! I must have been looking at an older spec then, apologies!

[trehman-gsma]

Will device remain a mandatory field in the next release?
(Referring to three legged use case where access token is tied to a device)

[bigludo7]

This is a fair question.
By the generic rule this API will require 3-legs but what if this API is used to track device (not linked to people) for a B2B customer? I tend to think we can have some borderline UC in 2-legs. I prefer to keep it as optional but if we prefer to remove it I understand.
@jlurien WDYT?

[jlurien]

If we make device optional this test case would need to be adapted. For 2-legged access, or even for 3-legged when a single device cannot be deducted from the access token, it would be an error, but not 400 INVALID_ARGUMENT (not compliant with schema) but 422 UNIDENTIFIABLE_DEVICE

[bigludo7]

Thank you @trehman-gsma for the review.
As usual very useful comment :)
We need a sync in particular with @jlurien to solve them as 2 of your comments are relevant as well for location-verification TC.

[jlurien]

OK with the clarifications, We may need to adapt some scenarios if we make device opcional and add support for 422 UNIDENTIFIABLE_DEVICE, but we make that changes along with the adaptations in the API specs

[jlurien]

If we make device optional this test case would need to be adapted. For 2-legged access, or even for 3-legged when a single device cannot be deducted from the access token, it would be an error, but not 400 INVALID_ARGUMENT (not compliant with schema) but 422 UNIDENTIFIABLE_DEVICE

[jlurien]

There may be situations as @bigludo7 suggests when the access token is valid but the device included in the request does not point to any device.

• Device can NOT be deducted from the access token:
  • device NOT included in the request body-> 422 UNIDENTIFIABLE_DEVICE
  • device included in the request body but not pointing to a known device -> 404 DEVICE_NOT_FOUND