Editorial corrections and alignments in Spring26 testing Artifacts#642
Open
PedroDiez wants to merge 1 commit into
Open
Conversation
PedroDiez
requested review from
bigludo7,
eric-murray,
jlurien and
rartych
as code owners
eric-murray
reviewed
Jun 19, 2026
Comment on lines
+86
to
+107
| # createResource MUST be replaced by applicable operationId for the tested operation | ||
| # schema names MUST be replaced by applicable values for the tested operation | ||
| # Applicable for APIs that does not own device nor phoneNumber concept | ||
| @{feature_identifier}_{createResource}_01_generic_success_scenario | ||
| Scenario Outline: Common validations for any success scenario | ||
| Given the request body property "$.{requestProperty}" is set to a valid {placeholder_suitable_text} | ||
| # Several clauses for request body property may apply depending on the operation | ||
| And the request body property "$.{requestProperty}" is set to a valid {placeholder_suitable_text} | ||
| And the request body is compliant with the schema at "#/components/schemas/<createResource>" | ||
| When the request "<createResource>" is sent | ||
| Then the response status code is 201 | ||
| And the response header "Content-Type" is "application/json" | ||
| And the response header "x-correlator" has the same value as the request header "x-correlator" | ||
| # The response has to comply with the generic response schema which is part of the spec | ||
| And the response body complies with the OAS schema at "#/components/schemas/<Resource>" | ||
| # Additionally, in case any success response has to comply with some constraints beyond the schema compliance | ||
| And the response property "<property>" matches the rule: <condition> | ||
|
|
||
| Examples: | ||
| | property | condition | | ||
| | $.xxx | yyy | | ||
|
|
Collaborator
There was a problem hiding this comment.
Was it intended to duplicate this test description? It's not clear why the template for a create resource test is needed twice.
Contributor
Author
There was a problem hiding this comment.
The intention is to have the exact test wording for device, phoneNumber and none of those concepts variants, for the API inititative to pick-up the applicable one:
- Line 66 defines the test scenario for an API that owns the phoneNumberConcept
- Line89 defines the test scenario for an API that does not own device nor phoneNumber concept
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
What this PR does / why we need it:
This PR deals with with some editorial corrections and wording alignment for Spring26 testing artifacts, as detailed in Issue #641
Which issue(s) this PR fixes:
Fixes #641
Does this PR introduce a breaking change?
Special notes for reviewers:
N/A
Changelog input
Additional documentation
This section can be blank.