How to create Identical GET request with different parameters in same project
Hi,
I'm struggling to create multiple requests that have identical resources (paths), same methods (a GET), but different Header Parms.
i.e. I need to create some tests to exercise the authentication/authorization handling for each API I'm testing (negative tests)
Each API can use either an 'Authorization' header (populated with a JWT token value) OR an 'X-Auth-Key' header (populated with some GUID/UUID)
So - I've got a number of negative test scenarios I need to test - the following test scenarios:
**both Auth headers are present and Authorization value is incorrect
**both Auth headers are present and X-Auth-Key value is incorrect
**only Authorization is present and value is incorrect
**only X-Auth-Key is present and value is incorrect
So - I need to create multiple requests for the same method type (GET) under the same resource (e.g. /v2/buckets ) with different headers - so that I can have a test case with those 4 scenarios mentioned above - with different headers present.
So I tried doing the following (see image)
HOWEVER - if I create multiple requests under the same GET method under the same resource, whatever header change I make for one request, changes the header parms for all - i.e. if I remove a header parm from 'Request 1' or change the 'TYPE' from 'HEADER' to 'PLAIN' - this change is applied to all the requests beneath the 'ListBuckets' GET method.
I've tried creating a clone of the resource - but you can't create a clone of the resource with an identical path.
You can't actually create another object at method level with the same HTTP verb - i.e. you can't create 2 GET methods under the same resource.
Does anyone know how to create multiple requests for the same resource and method when the request has different headers (Strictly speaking - actually different parameters) within the same ReadyAPI! project?
Short of manually executing a test step for a particular request within the Functional Tests object, then manually finding the relevant request in the APIs section of my project and then making relevant changes switching the 'TYPE' between 'HEADER' and 'PLAIN', then going back to the test and manually executing the next step and then going back to the APIs to then toggle the HEADER TYPE - I'm completely at a loss.
I've set HEADER values using groovy script and I've extracted HEADER values via groovy script - but I've never changed the parameter TYPE from HEADER to something else.
I did have a google about using groovy script to change a parameters type (i.e. from HEADER to PLAIN or PLAIN to HEADER) - but all I could find was about setting a specific HEADER value to a specific value - not actually changing the parm TYPE.
Am I just missing something obvious in the UI? There's gotta be a simple way around this.
As always I welcome any/all help/ideas/hints anyone can provide!
Cheers,
rich
This is perfect case for data driven test. Put all positive and negative cases together and also have an additional column in the data for status code which can be used in the assertion.
Again if certain request need two headers, certain request needs single header then that too can be achieved with the the help of data and a groovy combination with out creating n no of resources.
- Resource:
Create one method resource without any headers and this will be used in the test. Even if there are any, does not matter as it can be taken care in the groovy script.
- Data creation:
Here is the template for the data/CSV file for all the tests, just add your cases and expected status code.
| AuthHeaderValue | XAuthHeaderValue | IsAuthHeaderRequired | IsXAuthHeaderRequired | ExpectedStatusCode | |-----------------|------------------|-----------------------|-----------------------|--------------------| | valid | invalid | false | true | 400 | | invalid | invalid | true | true | 400 | | valid | invalid | true | false | 200 |
The meaning of the first row is to add only X-Auth-key to the request as it is defined in the data saying IsXAuthHeaderRequired is true and other is false. Of course this has to be done in the groovy that I mentioned earlier. But gives ability to control things in the groovy as needed.
Similarly, in the second row, both headers needed as per the data defined.
Third row is to use valid Authroization header.
- Test case:
Create data driven test using above created resource method and above created data file.
Use the assertion for status verification from data ie., ExpectedStatusCode
- Groovy:
Now there are two ways of adding the required headers to the request dynamically, the groovy I am talking about.
- With an explicit groovy script step which reads data from data file and add required headers based on the data defined. Of course this step has to be placed before rest request.
- Here the request header(s) will be added to the request and visible in the request editor.
- It has to be taken care for each row of the data (in the data driven tests) i.e., remove existing headers(because, previous run/row headers will be there) first (at least Authorization, and X-Auth-Key) and add headers as per the current row of data.
- Alternatively use Events/Listeners feature to add the headers dynamically beforeSubmit event.
- The advantage with this is that the header(s) will be added at runtime at object level.
- Headers aren't shown/visible in the request editor like in the above approach.
- No need of removal of Authorization, X-Auth-Key headers as they aren't there unlike #1 approach
- May be to avoid other test cases, execute this only for the specific test case/suite.
Hope you knew how to add header using groovy based on above conversations. Only thing is add respective header based on condition defined in data file.
The pseudo code :
Remove the headers, Authorization,X-Auth-Key if present.
If IsXAuthHeaderRequired is true, then add X-Auth-Key header to the request, and take the value from XAuthHeaderValue
Similary, add the header Authorization to the request if IsAuthHeaderRequired is true and value from AuthHeaderValue
Try this approach and let me know me know in case any trouble.