Closed jlurien closed 4 weeks ago
@jlurien Below are few thoughts from our side
Configuration variables
-We recommend to use gherkin syntax for variables and common setup can be achieved
using background section.
-We can consider to use separate configuration file which will have values
defined for variables of multiple feature files.
-For Payload we can consider separate json filesto be used for configuration.
We can use scenario outline with examples for different variable value
Request setup It can achieved as part of background step but we cannot guarantee of same setup(payload) for different methods of same API
For Open points We have to assume that device as an object is a configuration variable and each environment will provide a valid .
Scope of Test plan We can have recommendation as validation of response code and mandatory response parameters. Here decision has to taken if validation of 1 possible case is enough or all possible set of values?
@akoshunyadi @shilpa-padgaonkar
Hello Compiled with @patrice-conil and @GuyVidal for Orange perspective
First thanks @jlurien for the proposal.
Configuration variables +1 to @mdomale points
Request set-up We’re fine with @jlurien proposal globally – Perhaps we could have some adjustment after first use/examples.
Request Sending OK for us
Response validation OK for us
Open Points Device Identification For us we must follow what has been described in #127. We can probably contribute a Gherkin file to describe this.
Scope/reach of the testing plan We test only the interface and not the service itself.
Thanks for the feedback @mdomale. Some comments/questions below:
@jlurien Below are few thoughts from our side Configuration variables -We recommend to use gherkin syntax for variables and common setup can be achieved using background section.
Do you mean using
-We can consider to use separate configuration file which will have values defined for variables of multiple feature files.
In general, values for testing variables will be provided by the implementation to the tester for certain environment. We may considering defining a template with the set of variables that have to be provided.
-For Payload we can consider separate json filesto be used for configuration. We can use scenario outline with examples for different variable value
It is a possibility to move the request bodies to separate files. The advantage is that they can be used as values for scenarios outlines. But it will require maintaining many independent files for a test plan and defining clear file naming rules
Request setup It can achieved as part of background step but we cannot guarantee of same setup(payload) for different methods of same API
Agree. We can only setup a generic request body in Background, that may work for some generic scenarios testing generic errors, e.g. 401 without Authorization header, etc. We may define a default request body and then allow scenarios to overwrite the request body in the Background
For Open points We have to assume that device as an object is a configuration variable and each environment will provide a valid .
Testing of device is particularly complex, and will have to be aligned with outcome of discussion in #127. We may need specific scenarios to test the behaviour agreed in #127, and for other scenarios which do not test device support, just assume that a valid device object is provided as config variable.
Scope of Test plan We can have recommendation as validation of response code and mandatory response parameters. Here decision has to taken if validation of 1 possible case is enough or all possible set of values?
In the test plan we can provide different inputs to test different behaviours, but this would not test that implementation is right or that implementation is able to provide all possible responses. For example, in location-verification, if an implemention always answers with vwerificationResult: TRUE or FALSE, but never answers with PARTIAL or UNKNOWN, that would be difficult to test, unless we add some precondition to a test scenario requiring some input values that force that response.
@akoshunyadi @shilpa-padgaonkar
Thanks @bigludo7, please see my comments inline:
Hello Compiled with @patrice-conil and @GuyVidal for Orange perspective
First thanks @jlurien for the proposal.
Configuration variables +1 to @mdomale points
- about keeping standard Gherkin syntax. No use of specific [CONFIG:var] grammar but use
- environment values must be set in background. Let's keep it standard.
Commented above. Happy to keep it standard, but we'll have to figure out a way to express in our Gherkins that certain value for certain variable will be provided separately. We may use a separate template file and refer to it, or maybe write Scenario Outlines with placeholders. Tools that automatise execution of feature files may have problems with certain approach. Any feedback to handle this is welcome.
Request set-up We’re fine with @jlurien proposal globally – Perhaps we could have some adjustment after first use/examples.
Request Sending OK for us
Response validation OK for us
Open Points Device Identification For us we must follow what has been described in #127. We can probably contribute a Gherkin file to describe this.
Agree. It is key to close #127, and I would isolate testing tranversal device particularities from other more API-specific logic.
Scope/reach of the testing plan We test only the interface and not the service itself.
In the first iterations, I think that this is enough. In more mature phases we may try to test that service implementations follow the agreed implementation guidelines
To move the discussion further with some examples:
One of the main decisions to make is the level of detail for each scenario, specially regarding preconditions to setup the scenario. For example, for an API with device
in the input, there should be a case to test that there is compliance with the schema, but there are many possible variations for a wrong request body.
It is enough to design something like option 1, or should we try to achieve something more similar to option 2?
# Assuming that a default valid request body is setup in the Background
# Option 1: High level step, not indicating how to write the test.
# Tester can decide how to build the request body and how many cases to test
Scenario: Validate that device complies with the schema
Given the request body property "$.device" does not comply with the schema
When the HTTP "POST" request is sent
Then the response status code is 400
And the response property "$.status" is 400
And the response property "$.code" is "INVALID_ARGUMENT"
And the response property "$.message" contains a user friendly text
# Option 2: Details steps with explicit content to test.
# Implementations will know in advance the level of testing
Scenario Outline: Validate that device phoneNumber complies with the schema
Given the request body property "$.device.phoneNumber" is set to <value>
When the HTTP "POST" request is sent
Then the response status code is 400
And the response property "$.status" is 400
And the response property "$.code" is "INVALID_ARGUMENT"
And the response property "$.message" contains a user friendly text
Examples:
| value |
| foo |
| *092828# |
| 1234567890 |
| 12ft23333 |
| "" |
| +178931297489º17249017409º70937498º73297932790723097091 |
Scenario Outline: Validate that device ipv4Address complies with the schema
Given the request body property "$.device.ipv4Address" is set to
"""
{
"publicAddress": <publicAddress>,
"publicPort": <publicPort>
}
"""
When the HTTP "POST" request is sent
Then the response status code is 400
And the response property "$.status" is 400
And the response property "$.code" is "INVALID_ARGUMENT"
And the response property "$.message" contains a user friendly text
Examples:
| publicAddress | publicPort |
| 1.2.3.4.5 | 1234 |
| foo | 1234 |
| 1.2.3.4 | foo |
# etc, there will be lots of scenarios
Please, take a look to the example in https://github.com/camaraproject/DeviceLocation/pull/189, to illustrate the proposal here.
Please, take a look to the example in camaraproject/DeviceLocation#189, to illustrate the proposal here.
Hello @jlurien - From Orange side (checked with @patrice-conil) we're ok with your proposal provided in Device Location project. Thanks.
To move the discussion further with some examples:
One of the main decisions to make is the level of detail for each scenario, specially regarding preconditions to setup the scenario. For example, for an API with
device
in the input, there should be a case to test that there is compliance with the schema, but there are many possible variations for a wrong request body.It is enough to design something like option 1, or should we try to achieve something more similar to option 2?
# Assuming that a default valid request body is setup in the Background # Option 1: High level step, not indicating how to write the test. # Tester can decide how to build the request body and how many cases to test Scenario: Validate that device complies with the schema Given the request body property "$.device" does not comply with the schema When the HTTP "POST" request is sent Then the response status code is 400 And the response property "$.status" is 400 And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text # Option 2: Details steps with explicit content to test. # Implementations will know in advance the level of testing Scenario Outline: Validate that device phoneNumber complies with the schema Given the request body property "$.device.phoneNumber" is set to <value> When the HTTP "POST" request is sent Then the response status code is 400 And the response property "$.status" is 400 And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text Examples: | value | | foo | | *092828# | | 1234567890 | | 12ft23333 | | "" | | +178931297489º17249017409º70937498º73297932790723097091 | Scenario Outline: Validate that device ipv4Address complies with the schema Given the request body property "$.device.ipv4Address" is set to """ { "publicAddress": <publicAddress>, "publicPort": <publicPort> } """ When the HTTP "POST" request is sent Then the response status code is 400 And the response property "$.status" is 400 And the response property "$.code" is "INVALID_ARGUMENT" And the response property "$.message" contains a user friendly text Examples: | publicAddress | publicPort | | 1.2.3.4.5 | 1234 | | foo | 1234 | | 1.2.3.4 | foo | # etc, there will be lots of scenarios
Option 1 is preferable for us to ensure we provide flexibility to test implementer and not to restrict set of input static values. @akoshunyadi @shilpa-padgaonkar
Problem description The first version of the has to be enhanced with more detailed instructions to have consistent Test Plans across the WGs.
Possible evolution
Enhance the API testing guidelines with more detailed instructions.
Build necessary artifacts to support testing plans
Additional context
We include here a draft of the proposal, to trigger the discussion. When we reach enough consensus on the approach we can create a PR with the modifications.
Proposal
Testing implementations can use the Gherkin feature files with two different approaches:
For testing automation with some framework that take Gherkin as an input, such as Cucumber or Behave. For those tools, the steps have to be written in a way that allows to map them to a function with some optional arguments.
To be interpreted by a human as input for codification with another tool, which does not link to Gherkin natively, such as Postman, SoapUI, etc. In these cases, it is important that the scenario as a whole is unambiguous, and states how to build the request and validate the response.
Design principles
Feature structure
A feature file will typically test an API operation and will consist of several scenarios testing the behaviour of the API operation with different conditions or input content, validating that the response complies with the expected HTTP status, and that the response body meeets the expected JSON schema and some properties have the expected values.
Configuration variables
Most scenarios will test a request and its response. Commonly, values to fill request bodies will not be known in advance as they will be specific for the test environment, and will have to be provided as a separate set of configuration variables.
A first stage is to identify those variables, e.g. device identifiers (phone numbers, IP addresses), status of a testing device, etc. How those variables are set and feed into the testing execution will depent on the testing tool (Postman environment, context in Behave, etc)
In order to pass information between steps and make use of the variables, we have to agree on some syntaxis to refer to those variables. For example, Postman uses
{{variable}}
, Gherkin uses<variable>
for Scenario Outline, but this is not properly an Scenario Outline case. As a proposal, we may use something like [CONFIG:var].Example:
A background section at the beginning of the feature file may set common configuration variables and attributes for all scenarios, e.g.
apiServer
,baseUrl
,resource
, etcRequest setup
Typically the scenario will have to setup the request as part of the Given steps, filling the necessary path, query, header or body parameters. The guidelines can define a set of reusable steps for this, e.g.
When the HTTP "{method}" request is sent
Others may be quite specific for the API logic and have to be designed ad-hoc.
Open points
Some to start with...
Device identification
Identification of the device. There are many possible combinations that comply with the schema
Device
, and there are no clear guidelines about which ones are required in order to pass the certification.Do we have to test many combinations and validate which ones are passed in certain environment?
Do we have to assume that
device
as an object is a configuration variable and each environment will provide a valid one?This topic links with the discussion in https://github.com/camaraproject/Commonalities/issues/127
Scope/reach of the testing plan
Does then Test plan have to test only that the interface complies with the spec, or does it have to test that the service is correctly provided? For example:
Test that a device location is correctly verified or just that a valid response gets a 200, even if
verificationResult
value is not correct?Test that a device status for roaming is correct?