To.not.empty with undefined does not work

Ask the Experts and Postman Tips
1

I have some basic test which looks like:

var data = pm.response.json();

console.log(pm.response.json());

// Test response
pm.test('Required data test.', function() {
    pm.expect(data).to.not.empty;
});

if( data ) {

    var token = data.token;

    // Test missing token
    pm.test('Required access token test', function() {
        pm.expect(token).to.not.empty;  // THIS DOES NOT WORK WITH UNDEFINED
    });

    // Set collection {{token}} variable
    pm.collectionVariables.set('token', 'bearer ' + token);
}

It seems pm.expect(token).to.not.empty does not work with undefined. Am I right or doing something wrong?
Thanks.

2

Postman uses the Chai Assertion Library.

https://www.chaijs.com/api/bdd/#method_empty

From the blurb.

Because .empty does different things based on the target’s type, it’s important to check the target’s type before using .empty . See the .a doc for info on testing a target’s type.

From what I can tell, undefined is not covered. It’s not a string or array.

Be careful with using ‘data’ as a variable, as I think its a reserved word.

Looks like the test\assertion should be.

const response = pm.response.json();

pm.test('Token exists in response', function () {
    pm.expect(response.token).to.not.be.undefined;
    pm.collectionVariables.set('token', 'bearer ' + response.token);
});

You don’t really need to include “bearer” in the variable if you use the authorization helper for the subsequent requests.

image
image641×268 14.7 KB

The Postman Authorization helper appends the token value to the text Bearer to the request Authorization header, so you just need the token value in the collection variable.

pm.collectionVariables.set('token', response.token);
3

But .undefined is not enough controll. Is there a way to check all empty values including , null, undefined, false, 0, … ? Token has to be non empty string but can not throw an error if it is not set at all.

4

You can have multiple assertions within the same code block.

In some instances, you can also test more than one outcome.

Something like,

pm.test('Token exists in response', function () {
    pm.expect(response.token).to.not.be.oneOf([undefined, null, false, 0]);
    pm.expect(response.token).to.not.empty; // covers an empty array
    // pm.collectionVariables.set('token', 'bearer ' + response.token);
});

All of the assertions (pm.expect) have to pass before the test (pm.test) block will pass.

The following statement…

Token has to be non empty string but can not throw an error if it is not set at all.

This is bad practice. Your response should return the same response each and every time you send the same data.

Having dynamic tests that check if a certain key is in the response before running the test is brittle and not recommended.

You should test for what you actually want the response to return. Everything else should be a fail, instead of trying to cover the different potential errors in a conditional check.

If the API could potentially return null. Then you need a request that returns null, and the expected result should then be just that. That’s its returned null. It should return null every time you send the same data\request.

If you need a test that covers a missing token, then you need to get the API to return the missing token and then test that.

It’s not a valuable test checking for a response that can never happen. (So you do need a decent conversation with the developer on what the potential responses could be). Ideally this should be part of the API documentation\specification.

Can your API really return a empty array, null, undefined, false or 0 for the token value (as well as no token at all).

This might mean several requests to the same end point to get the test coverage that you need.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.