Wish: testing method check for empty bodies

[markstos]

In some cases, a server will return result.body as a null value, in other cases it will return an empty response. Practically, the difference often doesn't matter. It would be nice if a method checked that either of these were met:

expect(res.body).to.be.null or expect(res.body).to.be.empty

[rhwilburn]

Could you use res.noContent instead? or does that not work?

[markstos]

@rhwilburn I can't find documentation for res.noContent. Could you provide a link?

[rhwilburn]

@markstos It seems it is in a different library here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/5344bfc80508c53a23dae37b860fb0c905ff7b24/types/superagent/index.d.ts (search for noContent). It seems that Chai-Http supports superagent library intermixed with its stuff. Example:

chai.request(base_url).patch("/experience") .send({payload: "This is an invalid payload"}) .end((err, res) => { expect(res.noContent)

chai.request is part of chai, but patch, send and end are from superagent.

[austince]

Hey all, yeah chai-http is basically a chai wrapper around superagent. The docs for superagent can be found here: http://visionmedia.github.io/superagent/#response-properties

It looks like res.noContent is short for 204 == res.status || 1223 == res.status -- not sure if that solves your use case.

[markstos]

Thanks.

It sounds like res.noContent is specific to two status codes and would not help when checking that an empty body is returned with another status code.

For example, if some routes are expected to be called only by a frontend API and not by end users they might return a 404 status code and not bother to send content since the status code itself is sufficient for the API client to know what to do. 401 and 403 might be handled the same way.

In summary, An "empty body" shortcut check would still be nice to have.