When status code expectation fails, can't figure out which request failed

[sakovias]

In my Mocha tests I use before() hooks to send a number of requests to create data required for the actual tests. When one of the requests fails I end up with supertest's internal stack trace, which doesn't tell which request failed. The only indication of error is that one of the requests returned with unexpected status code.

Here's an example

var request = require('supertest');
var url = 'www.example.com';

request(url)
  .get('/')
  .expect(200)
  .end(function(err) {
    if (err) console.log(err.stack);
  });

request(url)
  .get('/test')
  .expect(200)
  .end(function(err) {
    if (err) console.log(err.stack);
  });

which gives the following stack trace:

$ node test.js 
Error: expected 200 "OK", got 404 "Not Found"
    at Test._assertStatus (/my/path/node_modules/supertest/lib/test.js:232:12)
    at Test._assertFunction (/my/path/node_modules/supertest/lib/test.js:247:11)
    at Test.assert (/my/path/node_modules/supertest/lib/test.js:148:18)
    at assert (/my/path/node_modules/supertest/lib/test.js:127:12)
    at /my/path/node_modules/supertest/lib/test.js:124:5
    at Test.Request.callback (/my/path/node_modules/supertest/node_modules/superagent/lib/node/index.js:831:3)
    at Stream.<anonymous> (/my/path/node_modules/supertest/node_modules/superagent/lib/node/index.js:1049:12)
    at Stream.emit (events.js:117:20)
    at Unzip.<anonymous> (/my/path/node_modules/supertest/node_modules/superagent/lib/node/utils.js:108:12)
    at Unzip.emit (events.js:117:20)

Is this an expected behaviour or this is something I can try to fix?

[viking]

I have the same problem. I've tried throwing the error from the end callback, but the stack trace is still unhelpful.

[sakovias]

I use the following function to throw an error in end() callback handler:

var _ = require('lodash');
var checkStatusCode = function(res, expectedStatus) {
  if (!expectedStatus) expectedStatus = 200;
  if (res.status === expectedStatus) return res;
  var description = res.req.method + ' ' + res.req.path;
  var data = (res.request && res.request._data) ? res.request._data : null;
  var paddedDataStr = (data && _.isPlainObject(data)) ? (' ' + JSON.stringify(data)) : '';
  var resStr = (_.isPlainObject(res.body) ? JSON.stringify(res.body) : res.body);
  throw new Error(description + paddedDataStr + ' ' + res.statusCode + ', expected ' + expectedStatus + '. Reason: '  + resStr);
};

This gives missing request details and proper stack trace. Of course it's up to personal preferences.

[AronVanAmmers]

@sakovias that's very helpful. IMHO this is how supertest should return details on assertion failures.

[georgecrawford]

Shame this is closed @rimiti. I encountered the exact same issue today. At a minimum, I'd like to include the line in my spec file which caused the error! Currently I just get this:

at Test._assertHeader (node_modules/supertest/lib/test.js:247:12)
      at Test._assertFunction (node_modules/supertest/lib/test.js:281:11)
      at Test.assert (node_modules/supertest/lib/test.js:171:18)
      at Server.assert (node_modules/supertest/lib/test.js:131:12)
      at emitCloseNT (net.js:1664:8)
      at _combinedTickCallback (internal/process/next_tick.js:136:11)
      at process._tickDomainCallback (internal/process/next_tick.js:219:9)

What's the current advice for how best to handle this in a Mocha test?

[LucasLeandro1204]

same @georgecrawford

[jk21]

@rimiti any chance to reopen this? i am also willing to work on a PR.

[broom9]

Seeing the same issue as well

[CatBakun]

Same for me, having supertest 4.x and supertest-session 4.x and also when using BLUEBIRD_LONG_STACK_TRACES=1 BLUEBIRD_WARNINGS=1

[yarick123]

Have the same problem with stack traces using e.g. expect(200) method. As this problem is already ~3 years old and, as mentioned by @CatBakun, it cannot be solved by Bluebird-Promises, I have to stop using this package :(

[saveman71]

For me, bluebird wasn't loaded by superagent, so I went inside the module and straight up replaced Promise by require('bluebird') to test things out, but it turns out, the longest stacktrace I can get with that is only:

      at Test.Object.<anonymous>.Test._assertStatus (node_modules/supertest/lib/test.js:268:12)
      at Test.Object.<anonymous>.Test._assertFunction (node_modules/supertest/lib/test.js:283:11)
      at Test.Object.<anonymous>.Test.assert (node_modules/supertest/lib/test.js:173:18)
      at localAssert (node_modules/supertest/lib/test.js:131:12)
      at node_modules/supertest/lib/test.js:128:5
      at Test.Object.<anonymous>.Request.callback (node_modules/superagent/lib/node/index.js:728:3)
      at IncomingMessage.parser (node_modules/superagent/lib/node/index.js:916:18)
      From previous event:
      at Test.then (node_modules/superagent/lib/request-base.js:239:31)
      at node_modules/core-js/modules/es6.promise.js:154:16
      at flush (node_modules/core-js/modules/_microtask.js:18:9)

3 more lines of nonsense... With jest if that can help.

[mrstif]

if it helps, you can stop performing expectations with supertest and use chai or jest instead.

const res = await request(url).get('/')
expect(res.status).to.eq(200)

This will return the exact file and line of the failed assertion. A bit more verbose... but it makes debugging much faster.

[Eitz]

Would a PR fixing this one be of interest here, @rimiti? I quickly fixed my version locally and the output is now the following:

  expected 200 "OK", got 404 "Not Found"
Error
    at Test.expect (/project/node_modules/supertest/lib/test.js:86:18)
    at Context.<anonymous> (/project/test/controllers/MyController.test.js:84:50)  <--- only meaningful line
    at callFn (/project/node_modules/mocha/lib/runnable.js:358:21)
    at Test.Runnable.run (/project/node_modules/mocha/lib/runnable.js:346:5)
    at Runner.runTest (/project/node_modules/mocha/lib/runner.js:621:10)
    at /project/node_modules/mocha/lib/runner.js:745:12
    at next (/project/node_modules/mocha/lib/runner.js:538:14)
    at /project/node_modules/mocha/lib/runner.js:548:7
    at next (/project/node_modules/mocha/lib/runner.js:430:14)
    at Immediate._onImmediate (/project/node_modules/mocha/lib/runner.js:516:5)
    at processImmediate (internal/timers.js:461:21)
    at process.topLevelDomainCallback (domain.js:138:15)
    at process.callbackTrampoline (internal/async_hooks.js:124:14)

Not sure it if would fix this one, it is still a bunch of non-sense but at least I can quickly know where the error failed. Maybe someone with more experience could get it better later.

[jpbochi]

what if we assume there's interest in a PR for this, then go ahead and open one? How would you solve it?

[Eitz]

Always a good assumption to have, @jpbochi. I will check it out later this week and open the PR. Stay tuned.

[jpbochi]

Always a good assumption to have, @jpbochi. I will check it out later this week and open the PR. Stay tuned.

I couldn't wait, sorry. Here's my solution: #690

[Eitz]

Nice, good stuff, thanks for PR. My solution was very similar to yours: wrapping the assert functions and preserving the stack from a new Error instance.

[jpbochi]

should I ping someone to review that PR?

[ze-ahmed]

Hello,

I got the same issue today: expected 200 "OK", got 404 "Not Found"

Has someone found a solution for this?

Thanks in advance.

[prios-chad-schwab]

This was fixed by @jpbochi PR released in 6.1.0.

[elitan]

Yep, upgrading to 6.x.x worked for me. I think this issue can be closed.