Test verbosity required?

I’ve learned that the library behind Postman’s testing is Chai Assertion Library (chaijs.com). According to its docs for BDD testing (linked from Postman docs) , several of the symbols it defines are optional “language chains” that make tests easier to read. For example, .to.be or .that.has, etc. That means these are equivalent:

pm.expect(pm.response).to.have.header('content-type'); // OK
pm.expect(pm.response).has.header('content-type'); // OK
pm.expect(pm.response).header('content-type'); // OK

However, that’s not the case with Postman’s objects when used without pm.expect():

pm.response.to.have.header('content-type'); // OK
pm.response.has.header('content-type'); // TypeError: Cannot read property 'header' of undefined
pm.response.header('content-type'); // TypeError: pm.response.header is not a function

I believe that’s a limitation (or bug) in the way pm.response is declared. As a new user of Postman’s tests, looking at its documentation and that of Chai, it’s frustrating and confusing to find this mixture of compatibility. It seems like Postman requires this verbosity and in a very specific way, not as flexibly as Chai allows.

I’d like to see Postman support syntaxes like those two examples that currently fail.

Alternatively, I’d like Postman to allow pm.expect(pm.response) to be written as pm.expect.response. For example:

pm.expect.response.header('content-type'); // proposed simpler syntax
1 Like

I actually like the proposal. The original thought was to not pollute the chai library. This is something that we can add in coming versions. Will get back to this when we do our next round of pm API upgrades.

Cc @kunagpal

1 Like

Great! I’m glad you and @kunagpal like the idea, @shamasis.

1 Like