Fall 25 Feature Files to provide schema context#492
Conversation
|
|
||
| Every feature will include a context after the `Feature` tag to provide relevant information about the implementation and execution of the tests. | ||
|
|
||
| For the feature context, the following template should be used: |
There was a problem hiding this comment.
Can you give some examples of how this template would be filled? Otherwise a .feature author may not be sure what to put in each section.
We should also decide whether the template always needs to be filled out , in case that is not necessary for certain .feature files (e.g. all the info could have been given in the Background assertions for certain APIs)
There was a problem hiding this comment.
Some examples @Kevsy (I can add it one in the PR). Good point to add an example
# Input to be provided by the implementation to the tester
#
# Implementation indications:
# * apiRoot: API root of the server URL
# * List of device identifier types which are not supported, among: phoneNumber, ipv4Address, ipv6Address.
# For this version, CAMARA does not allow the use of networkAccessIdentifier, so it is considered by default as not supported.
# * List of application server IP formats which are not supported, among ipv4 and ipv6.
#
# Testing assets:
# * A device object applicable for Quality On Demand service.
# * A device object identifying a device commercialized by the implementation for which the service is not applicable, if any.
#
# References to OAS spec schemas refer to schemas specifies in quality-on-demand.yaml # Input to be provided by the implementation to the tester
#
# Implementation indications:
# * List of device identifier types which are not supported, among: phoneNumber, networkAccessIdentifier, ipv4Address, ipv6Address
#
# Testing assets:
# * A device object which location is known by the network when connected. 2 distinct device are required for some scenario.
# * A device object identifying a device commercialized by the implementation for which the service is not applicable
# * A device object which location cannot be provided during test by the network.
#
# References to OAS spec schemas refer to schemas specifies in location-retrieval.yamlI can also add a sentence to reflect that:
We should also decide whether the template always needs to be filled out , in case that is not necessary for certain .feature files (e.g. all the info could have been given in the Background assertions for certain APIs)
| # Testing assets: | ||
| # * | ||
| # | ||
| # References to OAS spec schemas refer to schemas specifies in {apiname}.yaml, version {version} |
There was a problem hiding this comment.
As the API version is already indicated at the top of the Feature file, I would not add it again here, as it creates additional maintenance work when creating releases (vX.Y.Z -> vwip -> v....)
There was a problem hiding this comment.
Yes, good point @jlurien, that is already stated within Feature tag so better to avoid duplication and additional maintenance work
What type of PR is this?
What this PR does / why we need it:
This PR manages the topic raised in Issue #481, which indicates the lack of establising an schema context as indicated in PR #470 for event notification transversal gherkin template.
In this way, this PR proposes the following:
Update C01-device-errors.feature and C02-phoneNumber-errors.feature artifacts to provide such schema context and align with PR Add event-notification feature file template #470
Update API-Testing-Guidelines.md guide to document the
feature contextalready being used across Feature files also referencing to the schema contextWhich issue(s) this PR fixes:
Fixes #481
Does this PR introduce a breaking change?
Special notes for reviewers:
Changelog input
Additional documentation
N/A