new currentTag variable not obeying variableCasing directive

[jpjpjp]

I've been working with the variableCasing property in my config set to camelCase.

Recently I started writing some endpoints that use a snake case tag, ie "plaid_accounts" that return response bodies with a plaid_accounts property. I also have the following in my portman-config:

assignVariables:
  - openApiOperation: POST::*
    collectionVariables:
      - responseBodyProp: id
        name: <tag>Id
  - openApiOperation: GET::*
    excludeForOperations:
      - "GET::/*/{id}"
    collectionVariables:
      - responseBodyProp: <tag>[0].id
        name: <tag>Id

What I found, however, was that it was interpreting the value of in this case to "plaidAccounts" and failing.

I figured this was what I asked for when I set variableCasing to camelCase, so I've changed that to snakeCase and have been working through my scripts to modify all references to Portman variables to use snake casing.

The curious thing is that the variable currentTag is still being set in camelCase. I know that this was recently added to my request (thank you!), but it looks like some extra logic is needed to use the right casing.

Thanks!

[jpjpjp]

I have a small follow-up question here.

When setting casing to snake_case, the generated collection is still setting authorization to use the variable {{bearerToken}}. However, when this is set in .env-portman via PORTMAN_BEARER_TOKEN, the generated Postman variable is {{bearer_token}} so authorization fails when Newman is run directly from portman.

Is there a preferred way to override this behavior?

[thim81]

Both cases, since like uncovered edge cases, I'll do a deep-dive to try to iron out these kinks.

[thim81]

Do you happen to have a minimal repro case? That I can use for the debugging?

[jpjpjp]

Attached are a spec and a config that demonstrate the issue when variableCasing is set to camelCase

The spec includes
Archive.zip
endpoints based on the tag plaid_accounts. It defines a GET /plaid_accounts endpoint (which returns a response body with a property called plaid_accounts that includes an array of objects), and a GET /plaid_accounts/{id} which returns a single account object in the body.

The config includes the following rules

# Set a general rule to assign a postman id variable from the response bodies
# of any POST or GET requests
assignVariables:
  - openApiOperation: POST::*
    collectionVariables:
      - responseBodyProp: id
        name: <tag>Id
  - openApiOperation: GET::*
    excludeForOperations:
      - "GET::/*/{id}"
    collectionVariables:
      - responseBodyProp: <tag>[0].id
        name: <tag>Id

# Set a general rule to assign the ID path variable to the ID that was
# seen in a previous GET or POST request
overwrites:
  - openApiOperation: "*::/*/{id}"
    overwriteRequestPathVariables:
      - key: id
        value: '{{<tag>Id}}'
        overwrite: true

Here is (part of) the generated post request script for the Get All request:

// pm.collectionVariables - Set plaidAccountsId as variable for jsonData.plaidAccounts[0].id
if (_resPlaidAccounts0Id !== undefined) {
   pm.collectionVariables.set("plaidAccountsId", jsonData.plaidAccounts[0].id);
   console.log("- use {{plaidAccountsId}} as collection variable for value",jsonData.plaidAccounts[0].id);
} else {
   console.log('INFO - Unable to assign variable {{plaidAccountsId}}, as jsonData.plaidAccounts[0].id is undefined.');
};

From this we can see that Portman has applied the "camelCase" rule to the <tag> value, which should have been plaid_accounts and not plaidAccounts.

[thim81]

hi @jpjpjp

I'm a bit confused since this is the result that I get:

/plaid_accounts

/plaid_accounts/:id

Both are camelCase like configured from the tag:

[jpjpjp]

Hi @thim81,

I had expected the variableCasing directive to apply to the variable names, but not the variable values. In other words, regardless of the value of variableCasing, I would expect the value of <tag> to be an exact match of what it is in the spec.

With this expectation in mind I have the following in my portman-config.yaml:

  assignVariables:
  - openApiOperation: POST::*
    collectionVariables:
      - responseBodyProp: id
        name: <tag>Id
  - openApiOperation: GET::*
    excludeForOperations:
      - "GET::/*/{id}"
    collectionVariables:
      - responseBodyProp: <tag>[0].id
        name: <tag>Id
      - value: <tag>      # Used to overwrite the above assignment for mock servers
        name: currentTag  # See scripts/pre-mockRequestIdOverwrite.js for details

By setting the value of a variable called {{currentTag}} to the value of after making a GET request, I can use a pre-request script that generically overrides the id assignment for a version of my service that uses static data to a value that is preset as an environment var using the {{<tag>MockId}} naming convention.

Originally, I used the camelCase variable naming convention the script looked like this:

// Pre-request script to check for isMockService variable and update the 
// id on the path param to one that exists in the mock data.
let isMock = pm.collectionVariables.get("isMockService");
if (isMock) {
    let mockId = pm.collectionVariables.get(`${currentTag}MockId`)
    if (mockId) {
        console.log(`Setting ID for /${currentTag} to ${mockId} based on environment variable`);
        pm.collectionVariables.set(`${currentTag}Id`, mockId);
    } else {
        console.log(`There is no predefined ID set using the variable: ${currentTag}MockId`);
        console.log("If tests fail against a static mock data service, consider adding a value");
        console.log(`For the variable POSTMAN_${currentTag.toUpperCase()}_MOCK_ID in .env-portman`);
    }
}

However, this broke once I added a tag with an underbar in my spec. Because portman is returning the value of <tag> as camelCase, I had to modify my configuration of variableCasing: snakeCase all change all my logic to expect variables to be in snake_case. This is my current working script:

// Pre-request script to check for is_mock_service variable and update the 
// id on the path param to one that exists in the mock data.
let isMock = pm.collectionVariables.get("is_mock_service");
if (isMock) {
    let mockId = pm.collectionVariables.get(`${currentTag}_mock_id`)
    if (mockId) {
        console.log(`Setting ID for /${currentTag} to ${mockId} based on environment variable`);
        pm.collectionVariables.set(`${currentTag}_id`, mockId);
    } else {
        console.log(`There is no predefined ID set using the variable: ${currentTag}MockId`);
        console.log("If tests fail against a static mock data service, consider adding a value");
        console.log(`For the variable POSTMAN_${currentTag.toUpperCase()}_MOCK_ID in .env-portman`);
    }
}

I hope this make sense. As you can see I have a workaround for the current behavior, so if you think that it IS correct to apply the variableCasing property to the value as well as the name of a variable, I can work with it, especially since you have a PR in the work to properly name the bearer_token variable.

[thim81]

hi @jpjpjp

The variableCasing applies to the variable name when assigning it and to the overwrite values when applying it.
To allow the variable name to be used consistently. The created variable can be used in the same way to overwrite the variable.

globals:
  variableCasing: snakeCase

Assign

assignVariables:
  - openApiOperation: POST::*
    collectionVariables:
      - responseBodyProp: id
        name: <tag>Id
  - openApiOperation: GET::*
    excludeForOperations:
      - "GET::/*/{id}"
    collectionVariables:
      - responseBodyProp: <tag>[0].id
        name: <tag>Id

Results in:
pm.collectionVariables.set("plaid_accounts_id", jsonData.plaid_accounts[0].id);

Overwrite

overwrites:
  - openApiOperation: "*::/*/{id}"
    overwriteRequestPathVariables:
      - key: id
        value: '{{<tag>Id}}'
        overwrite: true

Results in
{{plaid_accounts_id}}

What would you expected as the results?

[jpjpjp]

I realized in reading through this thread that I didn't explain this problem very well. Here is a simplified config:

globals:
  variableCasing: snakeCase
assignVariables:
  - openApiOperation: GET::*
    collectionVariables:
      - value: <tag>      # Used to overwrite the above assignment for mock servers
        name: currentTag  # See scripts/pre-mockRequestIdOverwrite.js for details

Given this config if the value of <tag> is "plaid_accounts", what would you expect the value of currentTag to be?

I thought it would be "plaid_accounts", but in fact it is "plaidAccounts".

[jpjpjp]

You can reproduce the inverse problem by changing the variableCasing directive in the config attached to the previous message to snakeCase, and running it with the attached .env-portman file.

env-portman.zip

In this case we see that the appropriate value for the
<tag> variable is used in the generated post-response script for the initial GET request:

// pm.collectionVariables - Set plaid_accounts_id as variable for jsonData.plaid_accounts[0].id
if (_resPlaidAccounts0Id !== undefined) {
   pm.collectionVariables.set("plaid_accounts_id", jsonData.plaid_accounts[0].id);
   console.log("- use {{plaid_accounts_id}} as collection variable for value",jsonData.plaid_accounts[0].id);
} else {
   console.log('INFO - Unable to assign variable {{plaid_accounts_id}}, as jsonData.plaid_accounts[0].id is undefined.');
};

Unfortunately, in the generated collection, Portman interprets the PORTMAN_BEARER_TOKEN definition in .env-portman as a postman variable {{bearer_token}}, but still generates an Authentication rule based on the variables {{bearerToken}}:

[thim81]

hi @jpjpjp

This PR will fix the casing for the auth variable value.

[thim81]

FYI @jpjpjp This is now part of version 1.30.5 of Portman, so the auth casing is handled. Next up the variableCasing.