Skip to content

Fall 25 Feature Files to provide schema context #492

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rartych merged 3 commits into from
Jul 17, 2025
Merged

Fall 25 Feature Files to provide schema context #492

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
86212b0
Fall 25 Feature Files to provide schema context
PedroDiez Jul 1, 2025
f1370cc
updates after 1st round of comments
PedroDiez Jul 2, 2025
52a30b9
Fix typo
PedroDiez Jul 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions artifacts/testing/C01-device-errors.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,10 @@ Feature: CAMARA Common Artifact C01 - Test scenarios for device errors
* {path_to_device} has to be substituted to the JSON path of the device property in the body request, typically
"$.device" or "$.config.subscriptionDetail.device" for Subscription APIs

# This feature file is to be used by CAMARA subproject when Common error scenarios for operations with device as input either in the request body or implied from the access.
#
# References to OAS spec schemas refer to schemas specified in {apiname}.yaml

# Error scenarios for management of input parameter device

@{feature_identifier}_C01.01_device_empty
Expand Down
4 changes: 4 additions & 0 deletions artifacts/testing/C02-phoneNumber-errors.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,10 @@ Feature: CAMARA Common Artifact C02 - Test scenarios for phoneNumber errors
* {path_to_phoneNumber} has to be substituted to the JSON path of the phoneNumber property in the body request, typically
"$.phoneNumber" or "$.config.subscriptionDetail.phoneNumber" for Subscription APIs

# This feature file is to be used by CAMARA subproject when Common error scenarios for operations with phoneNumber as input either in the request body or implied from the access
#
# References to OAS spec schemas refer to schemas specified in {apiname}.yaml

# Error scenarios for management of input parameter phoneNumber

@{feature_identifier}_C02.01_phone_number_not_schema_compliant
Expand Down
38 changes: 38 additions & 0 deletions documentation/API-Testing-Guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,6 +127,44 @@ For the Feature description, API name and version must be included. When the fea
Feature: CAMARA Device location verification API, v0.2.0 - Operation verifyLocation
```

#### Feature Context

Every feature may include a context after the `Feature` tag to provide relevant information about the implementation and execution of the tests.

This feature context is RECOMMENDED unless it does not provide additional value (e.g. all the info could have been given in the Background section for a certain API)

For the feature context, the following template should be used:
Copy link
Collaborator

@Kevsy Kevsy Jul 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

@PedroDiez PedroDiez Jul 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some examples @Kevsy (I can add it one in the PR). Good point to add an example

Reference: https://github.com/camaraproject/QualityOnDemand/blob/main/code/Test_definitions/quality-on-demand-createSession.feature

    # 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

Reference: https://github.com/camaraproject/DeviceLocation/blob/main/code/Test_definitions/location-retrieval.feature

  # 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.yaml

I 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)


```
# Input to be provided by the implementation to the tester
#
# Implementation indications:
# *
#
# Testing assets:
# *
#
# References to OAS spec schemas refer to schemas specified in {apiname}.yaml
```

An example for this feature context is depicted below:

```
# 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 specified in quality-on-demand.yaml
```

### Environment variables

Commonly, some values to fill the request bodies will not be known in advance and cannot be specified as part of the feature file, as they will be specific for the test environment, and they will have to be provided by the implementation to the tester as a separate set of environment or configuration variables.
Expand Down