Updates the Gherkin test definitions

[albertoramosmonagas]

What type of PR is this?

Add one of the following kinds:

• tests

What this PR does / why we need it:

New scenarios — GEOHASHLIST area type support

• 3 happy-path scenarios: fully supported, partially supported, and unsupported area using areaType: GEOHASHLIST
• 400.17 — precision included together with a GEOHASHLIST request
• 400.18 — invalid geohash format
• 400.19–400.24 — general request validation: unexpected property, schema non-compliant body, missing/empty request body, empty area object, invalid x-correlator header
• 422.04 — unsupported area type (GEOHASHLIST not supported by implementation)
• 422.05 — unsupported geohash precision
• 422.06 — unsupported serviceLevel

Updates to existing scenarios

• POLYGON-specific wording removed from scenarios 01, 02, 03 and 09 — steps are now area-type agnostic
• XCorrelator schema reference updated to canonical CAMARA_common.yaml path
• 400.03 — BEST_EFFORT added as a valid serviceLevel value
• 400.04 — areaType: POLYGON added as explicit precondition
• 400.07 — converted to Scenario Outline with PLAIN and REFRESHTOKEN as examples; accepted error broadened to INVALID_CREDENTIAL or INVALID_ARGUMENT
• 422.01 — areaType: POLYGON added as explicit precondition
• 422.03 — missing When step added
• 400.02 — $.area.areaType added to required-property examples table
• 429.01 — tag casing fixed (too_Many_Requests → too_many_requests)
• All scenario tags renumbered to accommodate new scenarios

Which issue(s) this PR fixes:

Fixes #39

Special notes for reviewers:

Changelog input

 release-note
Updated test definitions for Sync26: added GEOHASHLIST area type test coverage, new general request validation scenarios, and multiple fixes and improvements to existing scenarios.

Additional documentation

This section can be blank.

docs

[camara-validation]

CAMARA Validation — PASS (with warnings)

0 errors, 2 warnings, 2 hints | Profile: standard

View full results

[albertoramosmonagas]

Hi @eric-murray, this PR updates the test definitions for the Sync26 RC and is the last pending change before we can trigger /create-snapshot on release issue #56 (r2.1 RC — predictive-connectivity-data v0.2.0). Could you take a look and approve when ready? Are there any other points left to address?

Thanks

[albertoramosmonagas]

Hi @eric-murray, we have to create the snapshot before July 31. Is there anything else we need to check here?

[eric-murray]

If I understand the API operation correctly, when precision is not specified and the area is a list of geohashes, the API can infer the precision from the precision of the geohashes.

First comment is that we should update the precision description in the YAML, which currently says "If not included the default precision level 7 is used by default".

Second comment is, can the API consumer request that the response has a higher precision than the precision of the geohashes? So if they provide a geohash as the input area that has precision 7, can they request that the output is, for example, four geohashes with precision 8? It does not make sense to request a lower precision, but could be reasonable to allow a request for a higher precision.

[albertoramosmonagas]

Thanks, @eric-murray. You’re right that the current description could be clearer.

The intended behaviour is that when area.areaType = GEOHASHLIST, the precision request property is not applicable and must not be provided. In that case, the response granularity is determined directly by the precision of the input geohashes.

To avoid ambiguity, I’ll update the description of the precision property to explicitly state that the default precision (7) only applies to POLYGON requests when precision is omitted.

[eric-murray]

Implication here is that the API consumer cannot ask for better precision than that of the geohashes they provide.

[albertoramosmonagas]

The intended behaviour is no. For GEOHASHLIST requests, the precision request property is not used. The response preserves the granularity defined by the input geohashes, so consumers cannot request a higher (or lower) precision than the one already provided in the request. We’ll make this explicit in the specification to avoid confusion.

[eric-murray]

Probably we should include additionalProperties: false in schema RetrieveConnectivityRequest if additional properties are to be explicitly excluded.

[albertoramosmonagas]

Good point. I’m happy to add additionalProperties: false at the top level of RetrieveConnectivityRequest.

As you mention, this does not propagate automatically to nested schemas, but I think applying it at the request root is a reasonable improvement and aligns with the intended validation behaviour.

[eric-murray]

This is a schema non-compliance, so would be caught by @predictive_connectivity_data_400.20_schema_not_compliant, but happy to keep this as a separate test for this specific non-compliance.

[albertoramosmonagas]

Agreed. Although this case is already covered by the generic schema non-compliance validation, I think there is value in keeping this as a dedicated conformance test since it verifies a common invalid request pattern explicitly.

[eric-murray]

Same comment, but happy to keep as a specific non-compliance test

[albertoramosmonagas]

Agreed as well. It's technically covered by the generic schema validation, but I think keeping it as a dedicated test improves readability and makes the expected behaviour more explicit for implementers.

[eric-murray]

Hi @eric-murray, we have to create the snapshot before July 31. Is there anything else we need to check here?

Apologies - so many things to do! I've reviewed now with some comments.

[albertoramosmonagas]

Hi @eric-murray, Thanks for the comments—they were very helpful. I've addressed all. Let me know if there's anything else left to do, or if we can move on to the next steps!