Forum Discussion

richie's avatar
richie
Community Hero
7 months ago

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

 

  • richie 

    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.

    1. 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.
    2. 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.

    • richie's avatar
      richie
      Community Hero

      Hey troyyerJP 

      Ha!  

      Been doing this for so long I can't even remember I answered that!

      I tried cloning the resource, I tried cloning the method and I tried cloning the request - all of them generated validation issues hindering having different parameter TYPES (enabling/disabling the HEADER parm from HEADER to PLAIN and back AGAIN) for the same API. 

      Admittedly, this approach isn't perfect cos my OpenAPISpec has 50 different APIs in it -  I'll need to clone the Service for each different negative test - but this is a way around what I need - so full cred to you! ;)

      Cheers!

      Rich

  • nmrao's avatar
    nmrao
    Champion Level 3

    richie 

    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.

    1. 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.
    2. 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.

    • richie's avatar
      richie
      Community Hero

      Hey nmrao 

      This is a cracking idea - hadn't even considered using a data driven approach to this.

      This is great - haven't touched ReadyAPI! for 4 years and this is really helping me get back into it.

      I'm still working on building the groovy using the snippets you provided in my other post.  Once I've finished that and I've got it working, I'm definitely coming back to this - cos the your approach is invaluable and transferrable for a multitude of other projects AND it will help improving my groovy too (which lets face it, I need all the help on that score! ;) ) 

      I'll definitely be coming back with some questions on this Rao - this will really help me going forwards.

      The help you provide is the difference between me getting my job done and not - so really - can't thank you enough 

      Cheers,

      rich

  • nmrao's avatar
    nmrao
    Champion Level 3

    richie 

    At the time of my post, the question was open, your below comment to @troyyerJP reply provoked me to think and come up with the above solution.

    Admittedly, this approach isn't perfect cos my OpenAPISpec has 50 different APIs in it -  I'll need to clone the Service for each different negative test - but this is a way around what I need

    A day later I noticed you closed it despite of my post (without any comments or likes), then I thought you aren't interested in solution / approach that I suggested.

    Glad you had a chance to look at it even after closing this as solved.

    Let me know if need with code snippets of groovy to achieve. Only problem is i don't have the tool / so little trial and error approach to be applied for the 100% working script.

  • richie's avatar
    richie
    Community Hero

    Hey nmrao 

    I think I marked the original answer as the solution before I'd even seen your data driven approach.  I'm also working 12/14 hour days right now so I was probably rushing.  I've changed which answer is the solution as your data driven approach is definitely the better option than just recloning the whole OAS back into the same project!

    holdit - you're answering groovyscript questions without even being able to debug your code within tool?  That's quite impressive - wish I could do that! 

    I'll start work on this as soon as I get some free time - cos this is definitely the way to do this!

    Cheers,

    Rich