Validating null or not null value

[shubhambajad]

Hi Team,

I have a scenario where I just need to check value should be present for the particular field I dont want to validate exact value so
for that in postman we do like pm.expect(response.id).should.be.not.null.

So, for this scenario do we have any predefine keyword in portman likewise we have for sucess, length or using extend test we need to add this kind of scenarios?

[thim81]

hi @shubhambajad

The Schema validation would be checking if the required fields are present.

{
  "version": 1.0,
  "tests": {
    "contractTests": [
      {
        "openApiOperation": "*::/crm/*",
        "schemaValidation": {
          "enabled": true
        }
      }
     ]
   }
}

If you want to do specific checks for a field, Portman provides contentTests.
Via content tests, you can target specific endpoints, and do checks like: key

All the options are described here: https://github.com/apideck-libraries/portman#portman---contenttests-properties
Or in the provided example: https://github.com/apideck-libraries/portman/tree/main/examples/testsuite-content-tests

It seems that for your question, a Portman like this example is what you are looking for:

{
  "version": 1.0,
  "tests": {
    "contentTests": [
      {
        "openApiOperationId": "leadsAll",
        "responseBodyTests": [
          {
            "key": "id"
          }
      ]
    }
  ]
}

where the key (String) = The key that will be targeted in the response body to check if it exists.

[shubhambajad]

@thim81 Yes but here we are matching exact value but my scenario is like it should not be empty means that field may consist of any value so just need to check any value should be present. Like, that field should be no null/empty.

Like in postman we can write "pm.expect(response.id).should.be.not.null."

[thim81]

Hi @shubhambajad

In the upcoming version, we are introducing the notExist content check.
Having a "notEmpty" or "notNull" value check might be interesting as well?

Would you check consider notEmpty => val !== null OR val !== ''

[shubhambajad]

ok.

For now I have used extent test to validate this scenario and it worked.

[thim81]

@shubhambajad After discussing with another Portman fan, we came to the conclusion that mapping all available Postman assertion would make Portman a bit convoluted and probably more difficult to maintain. The currently supported assertions in Portman are based on the common use-cases for content test. On the other hand Portman focusses on flexibility and extensibility, so we came up with this proposal:

The Postman/Newman application is using “Chai assertions” which means this kind of syntax:

pm.expect(target)assertion(value)

where target typically is a response body property name
and value is the value of the response body property. This is optional depending on the assertion.

example:

pm.expect(jsonData.company_name).to.eql("Spacex");
pm.expect(jsonData.company_name).to.not.be.null;

In Portman, we already have a value setting, which checks the value.
Most custom assertions: null, true, false, Nan, exists, ... typically don't need a value, so the proposal is to introduce a new contenTest setting in Portman, which you could set it like this:

{
  "key": "name",
  "assert": "to.be.null"
}

which would result in:

pm.expect(jsonData.company_name).to.be.null;

where we taken the “raw” assert value and inject it in Postman.

An additional positive effect is that we can chain them in 1 config:

{
  "key": "favourites",
  "value": "Greeks love frappé"
  "assert": "not.to.be.null"
}

which would generate 2 postman checks:

pm.expect(jsonData.favourites).to.eql("Greeks love frappé");

plus

pm.expect(jsonData.favourites).not.to.be.null;

Credits to Stella T. for this excellent proposal.

[shubhambajad]

@thim81 This new content test will be really helpful. It will save much time as well. Thanks for taking it in consideration.

[thim81]

We are actively working on the proposal, which should land in the next Portman version (potentially released today).

[thim81]

Portman content tests support the assert option since release 1.18.0.

For more info, have a look at the documentation or the content-test example

[shubhambajad]

@thim81 Thank you !