Add Test Definition for location Retrieval #119
Conversation
In order to prepare a release candidate added Test Definition for location Retrieval
Update following camaraproject/Commonalities#117 proposal.
|
@bigludo7 Once above comments are addressed then the feature file LGTM @akoshunyadi |
| And the response body should contain an error message indicating an invalid argument | ||
|
|
||
|
|
||
| @location_retrieval_04_Missing_MaxAge |
There was a problem hiding this comment.
maxAge is not mandatory in rc2: https://github.com/camaraproject/DeviceLocation/blob/main/code/API_definitions/location-retrieval.yaml
The test should not fail with a 400 error, just continue irrespective of age of known location.
There was a problem hiding this comment.
Agreed - Will fix.
| | phoneNumber | +34666111333 | | ||
| | networkAccessIdentifier | [email protected] | | ||
| | ipv6Address | 2001:db8:85a3:8d3:1319:8a2e:370:7344 | | ||
|
|
There was a problem hiding this comment.
Should we have testcases for when a location cannot be returned ? This can happen in two ways:
- The network does not have a location record for the device at all, e.g. it was trurned off a while ago.
- There is a location information in the network, but it does not satisfy the maxAge criterion.
There was a problem hiding this comment.
Agreed - added Test Case
There was a problem hiding this comment.
We can add the fact that the location is known by the operator to the Given steps
Fixed after Cetin review + added a TC to differentiate unauthenticated from unauthorized + added error code for rainy scenario.
There was a problem hiding this comment.
Fixed after @alpaycetin74 review + added a TC to differentiate unauthenticated from unauthorized + added error code for rainy scenario.
There was a problem hiding this comment.
Some more generic comments from a first review:
- We probably need to define a set of programmable steps that can be reused between scenarios and APIs.
- Scenarios must be implementable just with the information indicated in the scenario
- This is difficult task. We may need to identify the scenarios that we want to test and then decide on the best way to express them.
- I'm getting feedback from our QA team and will make another PR with a proposal as well
| | phoneNumber | +34666111333 | | ||
| | networkAccessIdentifier | [email protected] | | ||
| | ipv6Address | 2001:db8:85a3:8d3:1319:8a2e:370:7344 | | ||
|
|
There was a problem hiding this comment.
We can add the fact that the location is known by the operator to the Given steps
Co-authored-by: Jose Luis Urien <[email protected]>
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports MegaLinter is graciously provided by |
There was a problem hiding this comment.
Updated the file accordingly to the Commonalities Test Definition Specification & the feature file provided by @jlurien for Device-Verification.
This file will be updated in future in parallel with Device-Verification.feature file.
Aligned with change on error code
For expired access token changed code to UNAUTHENTICATED
In order to prepare a release candidate added Test Definition for location Retrieval
What type of PR is this?
What this PR does / why we need it:
In order to prepare a release candidate added Test Definition for location Retrieval
Which issue(s) this PR fixes:
Fixes #
Special notes for reviewers:
To be done consistently with camaraproject/Commonalities#94
Changelog input
Additional documentation
This section can be blank.