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,
.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.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