[jimfengjinhua]

What type of PR is this?

• tests
• correction

What this PR does / why we need it:

Fixes the mismatches between the test definitions and the API definitions reported in #207 for the Networks and Areas APIs. The Accesses items (item 4) will follow in a separate PR, because of upcoming Accesses API changes (#205, #206).

Networks (dedicated-network.feature)

• Item 1, initial network status: createNetwork_01 and createNetwork_03 now expect REQUESTED only, instead of REQUESTED or RESERVED. This matches the API info.description and the General Description, which both say a created network is always REQUESTED.
• Item 2, INVALID_SINK: new createNetwork_400.09_invalid_sink, aligned with the existing createAccess_400.09_invalid_sink.
• Item 5, create-then-read and delete-then-read:
  • new readNetwork_02_success_created_network: reads a network created by createNetwork and checks networkProfileId, serviceTime and serviceAreaId against the create request
  • new readNetwork_404.03_deleted_network: reads a network deleted by deleteNetwork and expects 404 NOT_FOUND

Areas (item 3)

• retrieveNetworkServiceAreas_400.07_invalid_coordinates:
  • expects INVALID_ARGUMENT instead of OUT_OF_RANGE
  • sends latitude and longitude as numbers instead of strings, so it tests the range and not the type
  • checks Content-Type, $.status and $.message, like the other 400 scenarios
• API change (dedicated-network-areas.yaml): retrieveNetworkServiceAreas now uses BadRequest400 instead of BadRequestWithRange400, so OUT_OF_RANGE is no longer declared.

Also fixed (not in the issue)

• Missing request set-up: createNetwork_400.04, 400.05, 400.07 and 400.08 changed a request body property without first setting the resource and a compliant request body. They now do, like the createAccess equivalents. This is the same flaw item 4 reports for Accesses.
• Ambiguous example row in createNetwork_400.05: the row oneOf networkProfileId or qosProfileName did not say which property to remove. A compliant body contains exactly one of the two, so removing the absent one leaves a valid body, and a correct server would return 201. The row now removes both $.networkProfileId and $.qosProfileName, which always violates the oneOf.

Which issue(s) this PR fixes:

Part of #207 (items 1, 2, 3 and 5; item 4 will be addressed separately)

Special notes for reviewers:

• Why OUT_OF_RANGE is removed rather than defined:
  • The Design Guide (3.2.1) describes OUT_OF_RANGE as being for "a given field [that] has a pre-defined range or a invalid filter criteria combination". Its only concrete guidance (4.1.1, pagination) says values outside the allowed range MUST be rejected with 400 INVALID_ARGUMENT.
  • Latitude 999 violates Latitude.maximum: 90 in the schema, so it is a plain schema violation.
  • The Areas API defines no condition that the schema can't express and that would return OUT_OF_RANGE. There is no provider limit on radius or area size, and no filter combination is described as invalid. An error code that no documented condition can trigger can't be tested.
  • If a provider limit is needed later, for example a maximum circle radius, OUT_OF_RANGE can be added back together with its definition.
• Tag names for item 5: the tag convention names the operation sent in the When step, followed by the status code (<operation>_<NN>_success_… or <operation>_<status>.<NN>_…). Both new scenarios send readNetwork, so they appear under readNetwork, not under createNetwork or deleteNetwork.
• Step wording for item 5: no existing scenario in this repo sends two requests, so the earlier operation goes in a Given step and each scenario keeps a single When. Comments on the phrasing are welcome.
• Not addressed: the pagination header assertions mentioned in the issue's additional context. That is a Commonalities question, as the issue notes.

Changelog input

 release-note
- Aligned the Networks and Areas test definitions with the API definitions (initial network status, INVALID_SINK, read after create and delete, invalid coordinates)
- dedicated-network-areas: removed the undefined OUT_OF_RANGE error code from retrieveNetworkServiceAreas

Additional documentation

docs