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