Supertest: [question]how to check not exist header field with supertest?

[HaveF]

If I set the express.js like this:

app.set("x-powered-by", false);

How to test this?

.expect('X-Powered-By', '', done)

will throw error: Error: expected "X-Powered-By" header field

.expect('X-Powered-By', null, done)

also not works.

Thanks for your help!

[ghost]

The headers are available as an object in the response object of the end callback - you can make assertions there. The manner in which you do this depends on the testing suite. Here's an example for mocha with chai:

var expect = require('chai').expect;
var request = require('supertest')('http://localhost:8000');

it('should not have the x-powered-by header', function(done) {
  request
    .get('')
    .end(function(err, res) {
      if (err) {
        return done(err); // done.fail(err) if using jasmine
      }

      // Ensure header does not exist
      expect(res.headers).to.not.have.key('x-powered-by');

      // All is good
      done();
    });
});

However, it would be nice if the expect method supported this. The syntax I am proposing is expect('header-name', false, ...). @mikelax, would you accept this as an enhancement? I can implement it for v1.2.0 if so.

[ericnewton76]

+1

I need to test my app for X-Frame-Options being emitted and a special url that prevents it in certain 3rd party cases that want to use my app in an iframe. and the allow-from (uri) isnt supported universally.

So my tests need to look for X-Frame-Options being emitted in one case, and NOT being emitted with a special url.

expect("x-frame-options",false) could handle this situation but i really dont like having the exact same function name utilized for so many different ways.

In order to prevent this "overload hell", I would've been more explicit with the names of non-body response expectation functions:

.expectStatus(200)
.expectStatus(200, "OK") //checks that the status message is precisely what you wanted
.expectHeader("x-frame-options",null) //expects NO header with this key
.expectCookie("mycookie").isNotNull()

Secondarily, expectCookie could include overloads:

.expectCookie("mycookie").isNotNull()
.expectCookie("mycookie","mycookieValue")
.expectCookie("mycookie",{"key1":"value1","key2":"value2"}) //would check either JSON object or key1=value1&key2=value2 type of multi values emitted via aspnet HttpCookie

@AhmedAKZM thanks for the workaround tip, ive been pulling my hair out trying to test this properly