References to OpenAPI specified for operationPreRequestScripts in variationTests don't work

[armen-ch]

Hi,

If OpenAPI reference is defined for operationPreRequestScripts in variationTests then the reference value/pattern of OpenAPI reference will be ignored and all the prerequest scripts will be generated for all targets.
Eg. the oas yaml contains 2 paths:

[. . .]
paths:
  '/v1/products':
    get:
      tags:
        - Lookup products
      operationId: lookup_products
[. . .]

  '/v1/system/products':
    get:
      tags:
        - Product Details
      operationId: get_products
[. . .]
    post:
      tags:
        - Product Details
      operationId: get_products_by_payload
[. . .]

and the Portman config looks like:

[. . .]
   "variationTests": [
      {
        "openApiOperation": "*::*",
        "openApiResponse": "400",
        "variations": [
          {
            "name": "missingParamValue",
            "overwrites": [. . .]
              }
            ],
            "operationPreRequestScripts": [
              {
                "openApiOperationId": "lookup_products",
                "scripts": [
                  "pm.collectionVariables.set('productsBody', request.data);\nconsole.log('productsBody');"
                ]
              },
              {
                "openApiOperation": "*::/v1/system/products*",
                "scripts": [
                  "pm.collectionVariables.set('systemProductsBody', request.data);\nconsole.log('systemProductsBody');"
                ]
              }
            ],
            "tests": {
             "contractTests": [. . .]
            }
          }
[. . .]

and the generated Postman collection will looks like:
for /v1/products path:

for '/v1/system/products':

sample portman config and oas yaml files are attached as zip archive:

test-api.zip

[thim81]

hi @armen-ch
I looked into the reported behavior.

The reason why the generated result was not as expected, is because of the double targeting:

• "openApiOperation": "*::*" on variationTests level
• and within the variation the "openApiOperationId" target as part of the "operationPreRequestScripts"

Portman variations are built with using a generic config but for variations, the targeting is focussed on the variationTests level.
As a workaround, you can define 2 variationTests for the 2 targets, see Archive.zip,

which results in:

[armen-ch]

Thank you @thim81 for the workaround solution.

My expectation was that targeting should work like filtering from higher level down to lower layer in hierarchy of nested blocks. Something like piping grep commands in Linux.
As for this example it would work as follows:
For all operations ("openApiOperation": "*::*") with "openApiResponse": "400" create variation tests and for "openApiOperation": "*::/v1/system/products*" targets of that Variation tests run "scripts": ["console.log('systemProductsBody');" ] and for for "openApiOperationId": "lookup_products" of that Variation tests run "scripts": [console.log('productsBody');"]

I think it would be more intuitive and will give more flexibility to Portman. What do you think?